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
| If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. You can buy it direct from the publisher for 30%-off and get instant acc |
Article Courtesy:
http://www.dba-oracle.com/t_proxy_connect_authentication.htm
