When you configure auditing to use the OpenEdge session ID as the auditing ID, you enable all audit-enabled databases so-configured to use a single auditing ID authenticated from a single authentication system. You can assert a single OpenEdge session ID as the auditing ID using the SECURITY-POLICY:SET-CLIENT( ) method. This method asserts the OpenEdge session ID to OpenEdge and validates it against the application trusted domain registry using a sealed client-principal object. Setting the OpenEdge session ID does not, in itself, generate an audit event. The process of initiating and managing a client login session for an OpenEdge session ID can, however, set several different auditing events. For more information, see Managing audit event context.

The configured auditing identity, itself, has no effect on database authorization. OpenEdge authorizes all run-time CAN* permissions and auditing privileges on a database, as well as database connections, using the database connection ID. When you use the OpenEdge session ID as the auditing ID, the user ID (database connection ID) used to authorize database access and audit privileges might not have the same value as the user ID (OpenEdge session ID) that is associated with the audit event records generated in a given audit-enabled database.

Note: CAN* permissions refer to the permissions for modifying tables and fields that you can set for each user in the OpenEdge Data Administration tool or character-mode Data Dictionary. Auditing privileges refer to permissions to perform auditing operations. For more information on CAN* permissions settings, see Manage ABL Applications. For more information on auditing privileges, see Configuring auditing privileges.