FWD » Core Development » Base Language

Implement support for the following:

CLIENT-PRINCIPAL resource

• CREATE CLIENT-PRINCIPAL statement
• CLIENT-PRINCIPAL resource and the following attributes/methods:
  • USER-ID
  • DOMAIN-TYPE
  • DOMAIN-NAME
  • SESSION-ID
  • SET-PROPERTY
  • GET-PROPERTY
  • EXPORT-PRINCIPAL
  • IMPORT-PRINCIPAL
  • SEAL

Builtin Functions

• DECRYPT
• ENCRYPT (runtime only)
• GENERATE-RANDOM-KEY

EXPORT/IMPORT-PRINCIPAL creates a byte representation of the CLIENT-PRINCIPAL resource, returned as a raw instance - as long we are consistent between the export and import, I don't think is required to produce the same byte array as 4GL. If we need this, then the investigation might be take some time to complete.

EXPORT/IMPORT-PRINCIPAL creates a byte representation of the CLIENT-PRINCIPAL resource, returned as a raw instance - as long we are consistent between the export and import, I don't think is required to produce the same byte array as 4GL. If we need this, then the investigation might be take some time to complete.

Agreed. We did the same thing for our basic support in RAW-TRANSFER (see #3549). I assume you will serialize/deserialize the same data as the original. Please document any detailed findings from your research for when we complete compatibility.

Greg Shah wrote:

• ENCRYPT
• DECRYPT
• GENERATE-RANDOM-KEY

These are dependent on SECURITY-POLICY:SYMMETRIC-ENCRYPTION-ALGORITHM attribute value, which sets the default cryptographic algorithm to use. At least we need a default value, which is AES_CBC_128.

Greg, why are these marked as VAR_RAW (and registered as global variables) instead of builtin functions, in progress.g:

      sym.addGlobalVariable("generate-pbe-salt"  , VAR_RAW          );
      sym.addGlobalVariable("generate-random-key", VAR_RAW          );
      sym.addGlobalVariable("generate-uuid"      , VAR_RAW          );

All of these are classified as "global builtin variables" since they don't take parenthesis. Even though the 4GL docs call them functions, the code looks like a var. They are handled in convert/variable_references.rules and have stubs in SecurityOps, though generate-uuid is fully implemented I think.

These metadata tables define the domains and the domain types:

_sec-authentication-domain.d
_sec-authentication-system.d

The -system.d table contains domain types, with records like:

"_extsso" "Built-in SSO module" no "" "" "020007AAIAAAAAAA==" "" "" 
"_oeusertable" "Built-in authentication module" yes "" "" "020007AAIAAAAAAA==" "" "" 
"_oslocal" "Built-in authentication module to the local OS user accounts" yes "" "" "020007AAIAAAAAAA==" "" "" 

I think the _oslocal mode delegates authentication to the OS user account and _oeusertable uses the _user metadata table to establish the user id.

The -domain.d contains records like:

"" "_oeusertable" "Default user domain" "" "" "" yes "" "" "" "" "" ? 1
"UNIX" "_oslocal" "Built-in domain for UNIX user accounts, reserved for database command line utilities" "34303a333b297e203533236a39202a" "" "" yes "" "" "" "" "" ? 2
"UNIXID" "_oslocal" "Built-in SSO domain to the UNIX process user, reserved for database command line utilities" "34303a333b297e203533236a39202a" "" "" yes "" "" "" "" "" ? 2
"WINDOWS" "_oslocal" "Built-in domain for WINDOWS user accounts, reserved for database command line utilities" "34303a333b297e203533236a39202a" "" "" yes "" "" "" "" "" ? 2
"WINDOWSID" "_oslocal" "Built-in SSO domain to the WINDOWS process user, reserved for database command line utilities" "34303a333b297e203533236a39202a" "" "" yes "" "" "" "" "" ? 2

1. _oslocal - delegate the authentication to the OS directory user accounts. We can just delegate to the FWD directory for now, and let the OS-local auth later.
2. _oeusertable - delegate the authentication to the metadata _user table.

I plan to configure in directory.xml a structure to define the domains, something like:

<node class="container" name="domains">
  <node class="domain name="">
     <node-attribute name="type" value="_oeusertable"/>
     <node-attribute name="enabled" value="true"/>
     <node-attribute name="decscription" value="Default user domain"/>
     <node-attribute name="access_code" value="random-key"/>
  </node>
  <node class="domain name="WINDOWS">
     <node-attribute name="type" value="_oslocal"/>
     <node-attribute name="enabled" value="true"/>
     <node-attribute name="decscription" value="Built-in domain for WINDOWS user accounts, reserved for database command line utilities"/>
     <node-attribute name="access_code" value="random-key"/>
  </node>
</node>

Their default access code values I think are just hex-encoded.

Is the _oslocal approach using something like PAM or does it just rely upon the user being already logged in?

Greg Shah wrote:

Is the _oslocal approach using something like PAM or does it just rely upon the user being already logged in?

The -domains table has some PAM-related fields, but they have no data in them. I'm trying to understand from the documentation how this works, as I couldn't work with this mode yet.

Something else: the _oeusertable and any other domain type allows any user ID to be specified, even if it does not exist in the _user table - and this user will be reported by USERID function.

The _oslocal mode I think just checks if the OS user exists; what it might also do is temporarily switch the client's OS permissions to that account. But I have no proof for this yet; if I use a custom domain with _oslocal type, it accepts any user ID specified via the USER-ID attribute (and this is reported by USERID function).

Please review 3752a rev 11295 - it contains the changes required for the current POC.

Code Review Task Branch 3752a Revision 11295

The result is very good. I've only found some minor issues:

1. In ConnectionManager.getDbClient()/setDbClient(), the use of cm.getLDBName(dbName).toLowerCase() is not safe. getLDBName() can return null. The existing code in setAuthenticatedUserid() also has this latent bug.

2. Please add null checking in SecurityOps.setDbClient(handle h, int64 dbNum) (for dbNum), SecurityOps.setDbClient(handle h, character ldbName) for ldbName.

3. SecurityOps.getAlgKeyLen() needs safety logic in case the algo name is malformed.

4. SecurityOps.validateClient() needs javadoc.

5. common-progress.rules needs a history entry.

I don't think this needs runtime testing. If it passes conversion testing for ChUI, it can be merged to trunk.

Greg Shah wrote:

1. In ConnectionManager.getDbClient()/setDbClient(), the use of cm.getLDBName(dbName).toLowerCase() is not safe. getLDBName() can return null. The existing code in setAuthenticatedUserid() also has this latent bug.

All these cases expect a valid DB name. If the name is invalid, I'll throw an exception, as we can't use the default DB.

If the name is invalid, I'll throw an exception, as we can't use the default DB.

OK, as long as the NPE does not occur. I guess the 4GL has some error condition for this case.

Greg Shah wrote:

If the name is invalid, I'll throw an exception, as we can't use the default DB.

OK, as long as the NPE does not occur. I guess the 4GL has some error condition for this case.

I mean the caller must have already validated this database name, and the APIs must never receive an invalid name - so instead of NPE, I'll throw an IllegalArgumentException.

3752a rev 11297 fixes the review issues.

I'm doing conversion testing next.

Conversion testing of 3752a rev 11297 passed.

Please merge to trunk.

3752a was merged to trunk rev 11293 and archived.

Added runtime/conversion support for SET-DB-CLIENT, GET-DB-CLIENT, DECRYPT, ENCRYPT and GENERATE-RANDOM-KEY - not all algorithms are supported, only AES_CBC is supported for now.
Added basic CLIENT-PRINCIPAL conversion and runtime.