Interwoven with data integrity in a successful auditing implementation is nonrepudiation. Nonrepudiation means that users cannot call into question their having performed an action if the action, in turn, generates a recorded audit event. Audit data that identifies what happened, where, and how is useful, yet incomplete if it fails to identify who performed the auditable application or database operation.

Each user ID specified in audit records must originate from a successful authentication to a user authentication system that OpenEdge trusts. It must be possible for the users authentication to be validated to ensure that the user ID was not compromised during transit from the authentication system to the database connection where the user ID is inserted into audit records. Only then can the user recorded in audit records be trusted to be accurate.

Prior to OpenEdge 11.0, the only trusted user ID source for OpenEdge applications was the _User table. However, reliance on the _User table meant that it was not possible for OpenEdge to validate that a user ID was coming from a trusted ABL application or other source. At issue was how an ABL application could use an external (to OpenEdge) authentication system and convey the resulting authenticated user ID to an ABL client in a manner that ensured that OpenEdge can trust the user ID in audit records.

The solution is to:

  • Provide built-in authentication systems that allow OpenEdge to authenticate user identities against the _User table and local operating system accounts
  • Support user-defined authentication systems configured with ABL authentication callbacks that allow OpenEdge to authenticate user identities against external user accounts
  • Support both built-in and user-defined authentication systems that allow the ABL application to become a trusted source for user authentication.

With the availability of an ABL client-principal object (ABL security token) and a trusted domain registry, OpenEdge can thus establish a trust relationship with either _User table, local OS, external, or ABL application-managed user account systems, and OpenEdge can accept as authentic all user IDs from these sources.

User authentication based on the _User table (using the -U and -P parameters or the SETUSERID function) also remains valid and can be used as the user ID in the auditing records.

Note: For this version of OpenEdge, only the _User table or the local OS user account systems are available for authentication in SQL.

If you are connected as a security administrator, you can:

  • Define your own authentication systems implemented either through your ABL application or through ABL authentication callbacks that you write and that OpenEdge can call directly to access external user account systems and otherwise manage the authentication process
  • Customize the built-in authentication systems provided by OpenEdge using ABL authentication callbacks that you can write to modify the built-in authentication process
  • Define domains that are configured to authenticate using a particular built-in or user-defined authentication system

If your ABL application implements its own authentication system, you must also make sure that:

  • The domain specified for a client-principal object is included in the trusted domain registry.
  • The application seals the client-principal object in the LOGIN state to begin a login session for a successful user authentication, or seals the object in the FAILED state for an unsuccessful user authentication.

For more information, see Learn about Identity Management and OpenEdge Programming Interfaces.

Note: If you continue to use the OpenEdge _User table for authentication, you need not do anything further to set up authentication. Also, connecting to an OpenEdge database by using either no user ID (the default connection identity) or the User ID (-U) and Password (-P) connection parameters is audited automatically when you have the audit service enabled.