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..
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:
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.