Application design considerations
- Last Updated: August 23, 2021
- 2 minute read
- OpenEdge
- Version 12.2
- Documentation
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 Managing audit 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 Application Security.
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 application server. For more information, see Application Security