Oracle Tips by Burleson Consulting
Today, systems with thousands of individual Oracle user ID's are not very common. Almost all enterprise applications (ERP packages like SAP, Oracle Financials) use pre-spawned Oracle connections that are created by a single Oracle user ID with names like AR or SAPR3.

The application server manages the connections to Oracle for us.
This is called a "proxy", the term proxy meaning an act where a 3rd party does something on our behalf. Unfortunately, when our end-users connect anonymously through a proxy, we do not have any end-user level security through traditional security tools like granting privileges or using roles and the only Oracle security is that is granted the ERP "master" user ID.

Who goes there?
From a DBA perspective, all database activity is being done by this single user and a query of the v$session view for an ERP does not identify any specific user, because they are connected to Oracle via the proxy on the application server.

This is a special nightmare for Oracle auditing, and all database auditing must now be done within the application server because is not aware of the "real" end-user, behind the proxy connection.
For complete information on Oracle auditing for ERP's see my notes in my bestselling security book "Oracle Privacy Security Auditing" with Arup Nanda.

The answer is to create a method whereby the ERP can maintain it's pre-spawned connection to Oracle while giving Oracle the ability to impose traditional security management (via roles, privileges, VPD's, etc.).

Oracle proxy connect authentication in 10gr2
To address this issue of unknown specific users within pre-spawned Oracle connections, Oracle has introduced a new proxy connection authentication in Oracle 10g release 2.
Under this new architecture, the ERP user ID is given limited privileges (create session only), and individual Oracle user ID's are created for each ERP user, using the traditional "create user" syntax.

Traditionally, you always connected to Oracle by only specifying your user ID and password:
connect scott/tiger

New with 10r2 proxy identification in SQL*Plus, the "connect" command has been enhanced to allow for a "proxy":

connect sapr3[scott]/tiger

You can also use this syntax to connect to SQL*Plus directly from the OS prompt:

root> sqlplus sapr3[scott]/tiger@mydb

As we see, we have a second, "proxy" user ID in the connect request (scott, in this case). When Oracle establishes the database connection, he will first connect as SAPR3 (who only has connect and resource privileges) and then open a proxy connection as scott.

Now, we have complete Oracle privileges and access control, just as if the scott user was connected, but in reality we have connected with the SAPR3 user, keeping our pre-spawned connection pool happy.
Note: To see the "proxy owner" of any Oracle session, you can see a proxy connection by using the sys_context package:

-- Here we see that Oracle has scott as the user ID
select user from dual;

USER---------------------------------------SCOTT

-- Here we call sys_context to reveal the proxy user:select sys_context('USERENV','PROXY_USER') from dual;SYS_CONTEXT('USERENV','PROXY_USER')---------------------------------------SAPR3

Disclaimer

This blog contains things about technology that I jot about, keep for my records. Some articles in this blog are not owned by me. They are for my reference only. In older posts the original links may not be there, its not intentional. Thanks for understanding.