Authentication and USoft

Traditional Client/Server mode

When using USoft in traditional client/server mode, both USoft and the RDBMS share the same user account. This account is managed by the RDBMS and USoft delegates authentication requests to the RDBMS. As a consequence, each USoft user must have an own RDBMS account and USoft makes a connection to the database using that account.

Account Funneling

In some cases it is preferable not to require an RDBMS account for each USoft user. Web users are a typical example; it is not usual to create database accounts for each Web application user. Managing Client/Server accounts on the operating system is another example. Alternative forms of account validation by USoft are therefore required. Because USoft requires at least one RDBMS account to access application data, users validated in an alternative manner will effectively use that RDBMS account. This is called account funneling: the RDBMS account being the funnel. User accounts that use the RDBMS funnel account are called funneling accounts. For these funneling accounts, it has to be decided how their credentials are validated. Validation Agent used to validate credentials can be specified for each USoft user in the USoft Authorizer.

Web applications (built using the Web Designer) always apply account funneling. This is because all requests are handled by a Rules Service, which is a server process and not, as in Client/Server, a user process. Thus, a web user is always validated using a Validation Agent.

USoft Client/Server can also make use of account funneling, to gain the advantage of other Validation Agents like the operating system: often it is preferred to validate user credentials against the operating system instead of the RDBMS system. To use account funneling, a Client/Server application must first be connected to a database, using its funnel account. To enable the Rules Engine to use a funneling account, the rulesengine object offers a "setuser" method. The user credentials specified in the setuser method are validated by the Validation Agent that has been specified for that user in the USoft Authorizer. If the SetUser request is successful, the USoft Rules Engine will continue on behalf of- and using the rights of the funneling account that was passed to the setuser request. An example of the SetUser method in a client/server context is provided here. Web applications implicitly apply the SetUser method, to tell the Rules Engine which user rights apply.

When the USoft Rules Engine is told to work for a user using the setuser method, it must first find the value that has been set for Validation Agent for the user in the Authorizer tables. There are eleven possibilities, depending upon the value of the Validation Agent:

•If the Validation Agent is set to 'RDBMS', the Rules Engine attempts a temporary logon to the database to check whether the RDBMS can authenticate this user.

•If the Validation Agent is set to 'USoft', the Rules Engine reads the password from the Authorizer table, and compares it with the password supplied by the user.

•If the validation agent for an application user is set to 'USoft Encrypted', the Rules Engine reads the password from the Authorizer table, decrypts the password supplied by the user, and compares the values.

•If set to 'LDAP' (Lightweight Directory Access Protocol), you can deploy the LDAP RDMI component to connect to a Directory Service such as Open LDAP or Microsoft Active Directory. The LDAP RDMI component will have to be specialized with LDAP binding information for this. Note that the "Operating System" option will validate against Active Directory when user accounts are configured in Active Directory.

•If set to 'IButton', you can use the ID number stored in IButtons to validate a user (see http:// www.ibutton.com for more information about IButtons).

•If set to 'External Service', the Rules Engine validates a user by calling a method named "validateCredentials" from an RDMI component named "ExternalService". The ValidateCredentials method is called with parameters: user name, password supplied by the user, agent information read from the Authorizer table, and the date of the last change of the account. The ExternalService RDMI component is intended to be built and implemented by the application developer.

•If set to 'Operating System' the Rules Engine validates the user credentials against the Windows operating system. The nearest domain controller running an active directory service is consulted. The user is allowed access if a bind to Active Directory is successful. The bind uses LDAP_AUTH_NTLM mode to avoid using readable passwords in network transfers. Note: failing authentication requests may cause account locking if so configured in Active Directory.

•If set to 'Single Sign On' the Rules Engine allows access to a user without checking credentials only if he already is logged on to the Operating System. If a password is specified, this option is equivalent to the 'Operating System' validation option.

•If set to 'No Authentication Required' access is granted to a User without any check at all.

•If set to 'Disabled' the Rules Engine does not allow access to this user.

•If set to 'Mapped Account' the credential check is delegated to the validation agent of the user specified as the mapped user. Account mapping allows authentication of a USoft account using the credentials of another account. For example, validation of a USoft application user named User1 using the password of an operating system user named User2. Typically, a set of USoft application accounts that serve different application roles might be authenticated by the password of one single account, which could be the password of the user's operating system account.

NOTE: In the interest of efficiency, the Rules Engine caches all records that it reads from the Authorizer tables. But if, for example, you change the user group for a user, the Rules Engine must reread the tables. To keep up-to-date, the Rules Engine must periodically refresh its cache. If a new password is set for a user, with validation agent set to "USoft", this password will immediately function.

If you want to allow users to change their own password, you must give them the right to read and update records in a number of Authorizer tables. To permit this, you should create a special user group for the Authorizer application that contains those users allowed to change their own passwords.

To create your own rules for password management (e.g. the length of the password should be greater than 10 characters), you must have your own table in the application to manage the use of passwords. You can use the PWDCredentials table component for this purpose. The Account Type field in the Application Users window specifies the purpose of the account, mainly for administrative purposes. An RDBMS setting signifies that the USoft account also is an RDBMS account. A traditional client-server logon would use such an account and generating RDBMS rights based on authorizer data is enabled.

A Funnel Account setting signifies that this is an Account that is also a database account and that the account is intended as a funnel for other USoft User accounts. The Funnel account would be the account used by a Rules Service. The account can also be a Client/Server generic account for Client Server applications that share one funnel account and use a modal startup dialog to set the funneling account to be used in the USoft session.

A Funneling setting signifies that the account does not need RDBMS access rights. The use of funneling accounts avoids the requirement for direct RDBMS access for users.