For ABL applications, OpenEdge supports for the following types of authentication systems:
OpenEdge internal (_oeusertable system) — OpenEdge performs the user authentication to the OpenEdge _User table accounts established in an OpenEdge RDBMS.
Although built-in, this authentication system can be configured with an ABL callback procedure that customizes the criteria for authentication, for example, limiting the number of times a user can login per day. This authentication system is supported for both OpenEdge-performed user authentication and SSO.
Local operating system (_oslocal system) — OpenEdge performs the user authentication to the local operating system user accounts (Windows or Unix).
Although built-in, this authentication system can be configured with an ABL callback procedure that customizes the criteria for authentication, for example, limiting the number of times a user can login per day. This authentication system is supported for both OpenEdge-performed user authentication and SSO.
ABL application — An ABL application performs the user authentication using either application-managed user accounts or an external user account system.
To support application-performed authentication, OpenEdge supports one built-in authentication system (_extsso) and the configuration of additional user-defined authentication systems. The ABL application must perform the user authentication (including creation of the sealed client-principal object) for both _extsso and user-defined authentication systems.These authentication systems are restricted to OpenEdge-performed SSO.
ABL callback — OpenEdge performs the user authentication through a user-defined authentication system implemented by an ABL callback that is independent of any application. OpenEdge runs the callback in the background. OpenEdge also seals the client-principal object when you use an ABL callback (unlike application-performed authentication where the application must seal the client-principal object).
Note: All authentication systems can be configured with an ABL callback that executes after an authenticated user identity is set. For example, the callback might initialize a user context store for use by other ABL sessions in a multi-tier application. For more information, see Using ABL callbacks in authentication systems.
To authenticate a user identity, an authentication system must be enabled for user authentication, have access to a valid set of user accounts, and be part of an OpenEdge security domain configuration that is also run-time enabled. With this configuration, the domain is then authentication-enabled. To use an authentication-enabled domain for authentication, you must include the domain name with the user name as the fully qualified user ID in an OpenEdge authentication operation
However, you can implement an authentication system even when a domain is not authentication-enabled. For domains that are not authentication-enabled, your application must implement the user authentication itself, either by managing its own store of users or by accessing an external source of user accounts such as LDAP. For more information on differences between OpenEdge and application-performed user authentication, see Authenticating and setting user identity.
Note: OpenEdge supports a default blank domain for a user that does not otherwise specify a domain.
ABL also supports several mechanisms to validate and assign a user identity through SSO, which works with all authentication systems. Regardless of the mechanism used, OpenEdge performs the actual SSO operation that validates the user identity.
For more information on OpenEdge support for, and configuration of user IDs, authentication systems, and security domains, see OpenEdge Getting Started: Identity Management.
OpenEdge internal ( _oeusertable system) — OpenEdge performs the user authentication to the OpenEdge _User table accounts established in an OpenEdge RDBMS.