OpenEdge allows you to write your own user account system in an ABL application, then use its sealed client-principal to set the authenticated user identity for ABL sessions and database connections. For domains configured with the built-in _extsso authentication system or a user-defined authentication system enabled for SSO only (see Defining and specifying the system type), you must implement the authentication system in an ABL application.
Note: Domains configured with the built-in _extsso or user-defined authentication systems, including those enabled for user authentication with ABL callbacks, cannot authenticate users for access to SQL clients or database utilities.
For application-implemented authentication:
You handle the management of user accounts, which you must define and store securely, including all required user identification information.
You determine the criteria for authenticating users, but the result must include an authenticated and OpenEdge-compatible user ID, and an additional unique value, that you can use to initialize the QUALIIED-USER-ID and SESSION-ID attributes of a client-principal object. If the user authentication fails, call the AUTHENTICATION-FAILED( ) method on the unsealed client-principal object to change its INITIAL state to the FAILED state, which properly registers a failed login audit event.
After you have authenticated a user identity and initialized the client-principal object to represent it, you must manually seal the client-principal object using the SEAL( ) method, which starts a login session for the user. This method requires the access code that is configured for the user's domain as an input parameter to cryptographically seal the security token that the object encapsulates. So, when you configure user-defined or _extsso domains be sure to make note of the access code that you assign to each one.
After you have sealed the client-principal object, you can then use it in SSO operations with the SET-DB-CLIENT function or the SECURITY-POLICY:SET-CLIENT( ) method to set the user identity for the ABL session and its database connections.
Caution: When you use the SEAL( ) method, you must protect the domain access code, which is exposed in your ABL code. To avoid this problem, use domains that are configured with a user-defined authentication system that is enabled for user authentication using an ABL callback.
When the user login session ends, the sealed client-principal is no longer needed. Terminate the login session by calling the LOGOUT( ) method on the object handle to change its LOGIN state to the LOGOUT state, which properly registers a logout audit event. You can then safely delete or re-initialize the client-principal object using the INITIALIZE( ) method.
You cannot take a user identity that must be authenticated with application-implemented user authentication and authenticate it for a connection to a database in the CONNECT statement or on the AVM startup command line. Only OpenEdge can authenticate users to startup a database connection. So, the initial database connection must be secured with a different identity, which you can reset with an application-authenticated identity using SSO.
Caution: Application-implemented user authentication is very flexible in that you can determine what constitutes a user and the criteria for their authentication. However, it is inherently less secure than using a built-in authentication system, such as _oeusertable or _oslocal, or a user-defined authentication system that is enabled for user authentication using an ABL callback. Using authentication systems that support OpenEdge-performed user authentication, you can complete the entire user authentication in a single operation with SET-DB-CLIENT, SET-CLIENT( ), or the CONNECT statement, which automatically seals the client-principal using the domain access code encrypted and stored in the trusted domain registry. Your application never needs to, and cannot, access the value of this code.
Therefore, implement application user authentication only if you have implemented a secured code-base environment, preferably on a locked-down authentication server, especially when exposing domain access codes within your application.
You handle the management of user accounts, which you must define and store securely, including all required user identification information.