Application-performed user authentication
- Last Updated: January 16, 2024
- 3 minute read
- OpenEdge
- Version 12.8
- Documentation
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.
_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-IDandSESSION-IDattributes of a client-principal object. If the user authentication fails, call theAUTHENTICATION-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_extssodomains 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-CLIENTfunction or theSECURITY-POLICY:SET-CLIENT( )method to set the user identity for the ABL session and its database connections.CAUTION: When you use theSEAL( )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 theINITIALIZE( )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.
_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.