The primary purpose of SSO-only authentication systems is to enable SSO for application-performed authentication. The built-in _extsso authentication system is an example of an SSO-only authentication system. You can extend _extsso by using either the Data Administration Console or the Data Administration tool to configure the built-in authentication system with a 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 case, the built-in _extsso authentication system is extended by the callback, ABLcallback1.

Figure 1. _extsso configured with an authentication callback procedure


Note that ABLcallback1 is the same callback configured to extend _oeusertable in Extending the built-in systems where OpenEdge performs user authentication. This callback extends any successful OpenEdge SSO operation using this authentication system by executing AfterSetIdentity. Enable Authentication in the above figure is disabled by default because SSO does not support authentication. Since authentication is disabled, the AuthenticateUser procedure in ABLcallback1 never executes.

When _extsso or an SSO-only user-defined authentication system is configured with an authentication callback, SSO proceeds as follows:

  1. An ABL application performs all the authentication, including the sealing of the client-principal object. Since Enable Authentication is disabled, the AuthenticateUser procedure in ABLcallback1 does not execute.
  2. The application invokes an SSO operation to assign the authenticated user identity with the sealed client-principal, using the SET-DB-CLIENT function or SECURITY-POLICY:SET-CLIENT( ) method. After the identity is set, OpenEdge calls the AfterSetIdentity procedure from ABLcallback1 to extend the default SSO authentication process. (see Creating an ABL authentication callback procedure for more information about AfterSetIndentity.)

    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.

If the application later uses the sealed client-principal from step 1 in another successful SSO operation, AfterSetIdentity also executes as in step 2.