Authentication delegate

The authentication delegate is a mechanism used to synchronously and asynchronously migrate users, groups, and roles from the LDAP server into the ACDB. When subjects are modified, removed from, or added to the LDAP server, these changes are propagated to the ACDB during the next LDAP server replication to the ACDB. Users are never automatically removed from the ACDB; however, if a user is removed from the LDAP server, that user cannot authenticate, even if they have a record in the ACDB. Users are “replicated” one record at a time. The replicated record belongs to the authenticating user.

Changes made to the ACDB are not replicated to the LDAP data store.

When a user logs in to the system:

The security services authenticate the user by accessing the LDAP server.

If the user is in the LDAP server, the information is replicated to the ACDB for that session and the user can access the secured system.

If the user is not in the LDAP server, an error displays and the session does not open.

Users with zero-length passwords cannot authenticate Before the authentication delegate presents credentials to the LDAP server, it immediately rejects zero-length passwords. Therefore, any users in the LDAP server with zero-length passwords cannot successfully authenticate to the system.

Figure 10-1: Authentication process

LDAP information is replicated to the ACDB as needed. The authentication is verified against the LDAP server each time a user authenticates to the system, and any user data is replicated once the authentication is determined to be successful.

The LDAP server does not have to be on the same platform as the installed Sybase products.

The authentication delegate:

Is configurable to one LDAP server.

Establishes a cache of connections to the LDAP server. This reduces the time taken to authenticate users and decrease load on both the LDAP server and the ACDB.

Provides flexible mapping from certificate binary and DNs to LDAP records. See “Certificate mapping” for details.

Maps credentials to a DN on the LDAP server.

The credentials supplied can be mapped to any attribute on the LDAP server (user ID—uid—the most common, and default case). Once the DN is established, the delegate “binds” to the LDAP server using the DN and the supplied password. This process validates the user’s password on the LDAP server, and if the LDAP server rejects the password, the authentication attempt fails.

Once the user has been authenticated, the record is replicated to the ACDB. Ensure that the LDAP account specified by the ldap.connection.bindname and ldap.connection.bindpassword properties has sufficient privileges on the LDAP server to access all of the relevant fields within a user’s LDAP record.

LDAP is not case sensitive, and ACDB is case sensitive. Therefore, if a user’s uid attribute within LDAP is modified to change case, a new replicated ACDB record is created when the user attempts to authenticate and the old record is orphaned.