For legacy applications that use the database _User table to authenticate users, you might not require any database configuration or coding changes to set up auditing security. Your existing usage of the User ID (-U)/Password (-P) or the SETUSERID function might be sufficient. This is especially true in a client/server configuration, where the client has direct access to the database and the application and database user are identical. However, note that where you connect to multiple databases, each database can generate auditing events associated with a different connection ID. If you want the auditing ID to be the same for all connected databases, you must be sure to authenticate the same database connection ID for each database.
If you want to use a single OpenEdge session ID as your auditing ID, regardless of individual requirements for database connection and access authorization, set the following database options:
Use Application User Id for Auditing — Described in an earlier section, this tells the database to use the OpenEdge session ID as the auditing ID.
Record Authenticated Client Sessions — This option ensures that client login session context for the OpenEdge session ID is recorded as part of the audit trail. For more information on using client login sessions with auditing, see Managingaudit event context.
To provide an OpenEdge session ID for your application, add the ABL code necessary to assert an OpenEdge session ID using the client-principal object and the SECURITY-POLICY:SET-CLIENT( ) method. For more information, see ApplicationSecurity .
Many legacy applications use their own ABL authentication systems to enforce a single application user ID. If you want to use this application user ID as your auditing ID, you can maintain your existing ABL authentication code. However, you must, again, set the appropriate database options and add the ABL code necessary to assert your application user ID as an OpenEdge session ID using the client-principal object and the SECURITY-POLICY:SET-CLIENT( ) method, as described in the previous paragraphs.
If you are developing a multi-tier application, especially one that conforms to the OpenEdge Reference Architecture (OERA), you must use the client-principal object and SECURITY-POLICY system handle to maintain the correct application user ID and auditing identity between application server clients and the AppServer. For more information, see ApplicationSecurity
Use Application User Id for Auditing — Described in an earlier section, this tells the database to use the OpenEdge session ID as the auditing ID.