Authentication and USoft

Previous Next

collapseTraditional client/server (C/S) mode

In the most traditional authentication mode, still used for C/S applications, USoft and the RDBMS share the same user accounts. Each user account is managed by the RDBMS and USoft delegates authentication requests for each user to the RDBMS. A separate RDBMS account must be created for each USoft user. USoft makes a connection to the database using that account.

In USoft Authorizer, users have Validation Agent = RDBMS.
collapseAccount Funneling

Alternatively, you can have multiple USoft users share a single RDBMS account. The RDBMS account is referring to as funnel account and the USoft users as funneling users.

In USoft Authorizer, users have a Validation Agent other than RDBMS.

Account funneling is applied to USoft URL-based applications built with Web Designer and Service Definer. Rules Engine requests are handled by a Rules Service, which is a server process and not, as in Client/Server, a user process.

Account funneling may also be applied to USoft C/S applications, in order to gain advantage of other Validation Agents such as the operating system:

• First connect the C/S application to the RDBMS using the funnel account.

•Now call the RulesEngine.SetUser() method to switch to a funneling account. Web applications implicitly call the SetUser() method to tell the Rules Engine which user rights apply.

•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 this call is successful, the Rules Engine will continue on behalf of the funneling account that was passed in the SetUser() request.

You can create a GUI implementation of this sequence of events.

collapseValidation Agent

The Validation Agent user attribute determines whether and how the user is authenticated:

Validation Agent

Description

Disabled

The Rules Engine does not allow access to this user.

External Service

The Rules Engine validates this 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.

IButton

You can use the ID number stored in IButtons to validate this user.

See http:// www.ibutton.com for more information about IButtons.

LDAP

This user is authenticated by having the LDAP (Lightweight Directory Access Protocol) RDMI component connect to a Directory Service such as Open LDAP or Microsoft Active Directory.

To make this work, the LDAP RDMI component will have to be specialised with LDAP binding information.

NOTE: The "Operating System" option will validate against Active Directory when user accounts are configured in Active Directory.

Mapped Account

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

No Authentication Required

No attempt is made to authenticate this user.

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.

RDBMS

The Rules Engine attempts a temporary logon to the database to check whether the RDBMS can authenticate this user.

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.

USoft

The Rules Engine reads the password from the Authorizer table, and compares it with the password supplied by the user.

USoft Encrypted

When specifying the password to access USoft, from the Command Line or a USoft Binder command line, an encrypted string must be supplied which USoft decrypts.

Contact USoft Support for implementation details.

USoft Hashed

The password is given a basic level of protection. It is saved in the database as a sha512 hash automatically, instead of you having to build your own password security component.

(null)

The Rules Engine does not allow access to this user.
collapseAccount Type

The Account Type user attribute indicates the type of account:

Account Type

Description

RDBMS

The USoft account is also an RDBMS account.

Used for traditional C/S authentication.

RDBMS rights are generated on the basis of USoft Authorizer data.

Funnel Account

The user account is also a database account.

The user account is intended as a funnel for other application user accounts.

Funneling Account

The user account is not also a database account.

Authentication is other than by the RDBMS.

Some arrangement is made to map the user account to a Funnel account for database access.

Account Type is mainly for administrative purposes. It also has an effect on the Update database grants routine.
collapseUSoft Authorizer as an authenticator

In the interest of efficiency, the Rules Engine caches all records that it reads from the Authorizer tables.

If a new password is set for a user, with validation agent set to "USoft", this password will immediately function. But if you change the user group for a user, or the rights for a user group, then the Rules Engine must reread the tables. To keep up-to-date, the Rules Engine must periodically refresh its cache. You can set the cache refresh frequency.
collapseChange-password feature

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 USoft Authorizer application that contains those users allowed to change their own passwords.

 

 

See Also

User account mapping

How to change the Rules Engine cache refresh frequency

Authorising users to change their password

Using RulesEngine.SetUser()

Example: Client/server login dialog

MS SQL Server authentication