Authentication systems that OpenEdge user authentication operations can use to directly perform the authentication:
Built-in _oeusertable - This authentication system is configured with the OpenEdge internal user account system defined in the hidden _User table of OpenEdge databases. This user account system is managed entirely by OpenEdge database administration tools. Users defined in the database _User table accounts are defined with both a user name and the name of an OpenEdge domain, which is always configured with the _oeusertable authentication system. The _User table accounts also support a blank user identity in which both the user name and domain are defined with the empty string (""), and the OpenEdge blank domain serves as the default domain for any user ID specified with only a user name.
Built-in _oelocal - This authentication system is configured with the native user accounts on the Windows or UNIX-based operating system where OpenEdge runs, with all of the user account security that the particular operating system provides. Users defined in Windows user accounts can be identified by both a user name and a Windows domain name. UNIX user accounts support only user names within a single domain. However, authentication to any local OS user account requires a user ID that includes the OS-defined user name and the name of an OpenEdge domain that is configured with the _oslocal authentication system. OpenEdge domains defined to work on a Windows system can also be mapped to particular Windows domains, as required.
User-defined authentication systems - These authentication systems are configured with ABL authentication callbacks that manage user accounts or access external user account systems for user authentication. These user-defined authentication systems must also be enabled for user authentication. To work with OpenEdge user authentication operations, owners of the user accounts accessed by an ABL authentication callback must be defined with a user name in an OpenEdge domain that is configured with a user-defined authentication system that is, itself, configured with the same ABL authentication callback. For more information on user-defined authentication systems and configuring them with ABL authentication callbacks, see Defining and specifying the system type.
Authentication systems that require an ABL application to implement and perform the user authentication using application-managed user accounts or an external user account system, similar to ABL authentication callbacks. These authentication systems include the OpenEdge built-in _extsso authentication system and any user-defined authentication system that you enable for OpenEdge SSO only. An application-implemented authentication system is enabled for SSO only so any OpenEdge domain that is configured with that authentication system cannot be part of a user identity that OpenEdge can authenticate, but once authenticated (by the application) OpenEdge can establish using an SSO operation. An SSO-only authentication system can be configured with an ABL callback to perform post-processing after an OpenEdge SSO operation establishes a user identity that is authenticated in a corresponding domain.
|
Identity application
|
Description
|
|
Database connection identity
|
A user identity that has been authenticated for or assigned to the database connection. An OpenEdge RDBMS authorizes all access to specific database tables and fields using the database connection identity.
The identity for a database connection can be authenticated directly by OpenEdge when the connection is established from an ABL client, SQL client, or database utility. In ABL, the initial database connection identity can be bound to the identity already established for the ABL session to which the database is connected (see ABL session identity in this table). Also in ABL, the initial database connection identity can be changed by authenticating a new identity or by validating a new identity from a previously sealed security token.
Note: The ABL USERID function returns the current database connection ID (qualified or non-qualified, as appropriate) for a database connection, regardless of how it is set.
|
|
ABL session identity
|
A user identity that is associated with an ABL session, independent of any databases connected to the session. The ABL session identity can be used to authorize or identify user access to application features in a database-independent fashion. These can be features that are entirely application-defined or that are supported specifically by OpenEdge, such as the auditing identity.
The identity for an ABL session can be authenticated directly by OpenEdge at the request of the ABL application, or the ABL application can perform its own authentication of the session identity as a user-defined authentication system. An ABL session can also set its identity by validating a previously sealed security token. For example, it can set its identity from the sealed security token representing the identity of an existing database connection or another ABL session (see ABL application identity).
All options for authenticating or setting ABL session identity depend on ABL functions and methods that authenticate the identity and seal the security token for the session, or validate the session identity from a previously sealed security token.
|
|
ABL application identity
|
A common user identity established by a multi-tier application for use by all OpenEdge sessions that participate in handling a single user action or request. The is the same as the ABL session identity with its scope extended by application code to multiple ABL sessions and database connections.
Typically, the application user identity is shared between a single AppServer client and the AppServer agent or agents that process client requests. Depending on the application session model, this single application user identity can also be shared between a single ABL client session and multiple AppServer instances. In addition, any given ABL session can use this single application identity as both the ABL session identity and the identity of any or all database connections required by the session or application.
You can set the application identity from a user ID that is authenticated in a single controlling session, which is typically an AppServer session that authenticates and manages the application identity for all ABL clients that log users into the application.
For more information on multi-tier applications, the OpenEdge AppServer, and application session models, see OpenEdge Getting Started: Application and Integration Services.
|
|
Auditing identity
|
The designated user identity that OpenEdge auditing stores in audit event records for an audit trail.
There is no functionally independent auditing identity. Instead, the auditing identity is set from one of the other established identities, depending on the application configuration.
The auditing identity for the audit trail recorded by any database is the current connection identity for that database, and this is the only source of auditing identity for SQL or database utilities. However, you can also set a database option to set the auditing identity from the identity of any ABL session that connects to the database, effectively making the database connection identity the same as the ABL session identity (see database connection identity in this table). In this way, you can configure auditing for every database that is connected from a given ABL session so that all audit trails for that session (or even the entire application) are associated with the same user identity. Also, any time you explicitly authenticate or set a new connection identity for a database, this becomes the new auditing identity for that database as well.
Note: The ABL USERID function returns the user ID (qualified or non-qualified, as appropriate) for the current auditing identity, regardless of how it is set.
|