Using ABL to implement user authentication systems
You can implement an application-independent, user-defined authentication system using an ABL callback to do the required user authentication. After programming the callback, you use either the Data Administration Console or the Data Administration tool to configure the authentication system with the callback. (See the online help for each tool for more information.)
The following figure shows the Authentication Systems dialog in the Data Administration tool. It lists the available authentication systems in the Domain Type column. In this example, A new, user-defined authentication system, LDAP, is configured to use a callback, ABLcallback2, for user authentication. This callback validates user credentials through an external user account system managed by the Lightweight Directory Access Protocol (LDAP).
Note: Although you can use ABL authentication callbacks to configure external authentication services (user verification based on LDAP, for example) in an OpenEdge domain, the details for implementing external authentication services are beyond the scope of this documentation.
Figure 17. A user-defined authentication system implemented by a callback
When LDAP is configured with ABLcallback2, user authentication proceeds as follows:
1. The AVM executes the AuthenticateUser procedure in ABLcallback2 in response to an OpenEdge-performed authentication operation, such as the CONNECT statement invoked with specified User ID (-U) and Password (-P) connection parameters or executing the SECURITY-POLICY:SET-CLIENT( ) method invoked with an unsealed client-principal object initialized with the required user credentials.
2. AuthenticateUser processes user credentials by executing a user-validation procedure (based on LDAP in this example).
Depending on whether the user authentication succeeds or fails, you set an appropriate error code that is returned to the AVM when AuthenticateUser execution completes. (see Creating an ABL authentication callback procedure for more information about AuthenticateUser.)
3. AuthenticateUser can perform whatever further authentication, or other checking, that you might require. For example, you might check whether a user has exceeded a set number of logins in a given time period, and generate a customized error message if that condition exists.
Also because the client-principal is unsealed at this point, the procedure can add additional information (user roles, for example) to the object.
4. If the AuthenticateUser procedure returns successfully, the AVM seals the client-principal object in the LOGIN state. The AVM uses SSO to assign the authenticated identity to a database connection or an ABL session.
5. After using SSO to assign user identity, the AVM executes any optional AfterSetIdentity actions defined in ABLcallback2 to extend the default SSO operation.
Because the client-principal object is sealed, you cannot modify or add information to the client-principal object. However, you can initiate other actions, such as changing context information stored in an OpenEdge database, for example.
If the application later uses the sealed client-principal from step 4 in another successful SSO operation, AfterSetIdentity also executes as in step 5.
