Database
Security
Proxy Authentication |
Oracle proxy authentication was first introduced in Oracle8i to provide application developers more flexibility in designing multi-tier architectures. Multi-tier architectures became popular in the 1990's due to their ability to meet the scalability demands of Internet-based applications. They consist of two components — a middle tier and a backend database. An Oracle based multi-tier architecture would consist of the Oracle Fusion Middleware and the Oracle Database. Today many applications simply authenticate users to the middle tier and the middle tier connects to the database as one "big user". This model works as long as the end user identity isn't required in the backend database. Identity propagation has become increasingly important for both regulatory compliance and overall security, and can be achieved in several ways.
The most common method used by existing multi-tier applications is to pass a client identifier from the middle tier to the backend database across an existing "big user" connection. Client identifiers were introduced in Oracle Database 9i to enable an application to pass an identifier across an existing thick or thin JDBC connection from the middle tier to the backend database. When Oracle database auditing is turned on, the client identifier will be recorded in the Oracle database audit trail. Once initialized, the client identifier value can be referenced in the database inside any SQL or PL/SQL statement.
STEVE> select sys_context('userenv','client_identifier') from dual;
To set the CLIENT_IDENTIFIER attribute with OCI, use the OCI_ATTR_CLIENT_IDENTIFIER attribute in the call to OCIAttrSet(). Then, on the next request to the server, the information is propagated and stored in the server sessions. For example:
OCIAttrSet (session,
OCI_HTYPE_SESSION,
(dvoid *) "appuser1",
(ub4)strlen("appuser1"),
OCI_ATTR_CLIENT_IDENTIFIER,
error_handle); /* OCIError *error_handle */
For applications that use JDBC in a connection pooling environment, the client identifier can be used to identify which user is currently using the database session. To set the CLIENT_IDENTIFIER for JDBC applications, use the following oracle.jdbc.OracleConnection interface methods:
setClientIdentifier() : Sets the client identifier for a connection
clearClientIdentifier() : Clears the client identifier for a connection
Please refer to the Oracle Call Interface Programmer's guide and the Oracle Database JDBC Developer's Guide and Reference for additional information.
Alternatively, applications can use traditional proxy authentication to authenticate as the real end user to the backend database and then proxy to the one "big user". This also works with Oracle Enterprise User Security. With Enterprise User Security, a shared schema could be defined in the backend database, dramatically reducing the number of database accounts required in the Oracle database to handle the end users. Prior to Oracle Database 10g Release 2, Oracle proxy authentication only worked with thick or thin JDBC connections. In Oracle Database 10g Release 2, Oracle introduced command line proxy functionality.
Command line proxy functionality is particularly useful for batch jobs executing on the backend server and connecting as the one-big user.
SYSTEM> grant create session to Steve identified by steve_password;
SYSTEM> grant create session to sales_app_dba identified
by sales_app_dba_password;
SYSTEM> alter user sales_app_dba grant connect through Steve;
SYSTEM> connect Steve[sales_app_dba]/steve_password;
SALES_APP_DBA>
Note that Steve's password could alternatively be stored in an Oracle Wallet using the secure external password store feature. Command line proxy, used in conjunction with the secure external password store, provides an elegant solution for securing batch jobs.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||