Using the database connection ID
- Last Updated: January 17, 2024
- 2 minute read
- OpenEdge
- Version 12.8
- Documentation
Using the database connection ID
When you configure auditing to use the database connection ID (the default), you enable each audit-enabled database to use a different auditing ID that is potentially authenticated to a different authentication system. You can use all of the following ABL elements to assert the database connection ID as the auditing ID:
- User
ID (
-U) and Password (-P) startup and connection parameters (at client startup or in theCONNECTstatement), which authenticate and assert a connection ID from the database_Usertable -
SETUSERIDfunction, which authenticates and asserts a connection ID to a connected database from the database_Usertable -
SET-DB-CLIENTstatement, which asserts a user ID that is authenticated to a trusted domain registry (database- or application-defined, depending on your configuration) and asserts that ID as the connection ID for a specified connected database using a sealed client-principal object -
SECURITY-POLICY:SET-CLIENT( )method, which asserts a user ID that is authenticated to a trusted domain registry (database- or application-defined, depending on your configuration) and asserts that ID as the connection ID for all connected databases that do not already have an explicitly set database connection ID using a sealed client-principal object
If you set the
database connection ID with one of the first three elements, using
the SET-CLIENT( ) method has no effect
on this setting. Whatever way you set the database connection ID,
the act of doing so generates an appropriate audit event (if auditing
is enabled), and the resulting database connection ID, for each
database where auditing is enabled, becomes the auditing ID.
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. So, when you take the default and specify
the database connection ID as the auditing ID, it happens that the
same user ID used to authorize database access is also associated
with the audit event records generated in a given audit-enabled
database.
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 and Application Security. For more information on auditing privileges, see Configuring auditing privileges.