Learning Objectives
Supplement
Selecting the link title opens the resource in a new browser window.
Learning Aid
Use the learning aid Style Considerations for more information on the style
considerations for the Oracle 11g Database used in this course.
Enterprise User Security, also known as EUS, addresses the user, administrative, and
security challenges by centralizing storage and management of user-related information
in a Lightweight Directory Access Protocol, commonly known as LDAP-compliant
directory service.
When an employee changes jobs in such an environment, the administrator needs to
modify information only in one location (the directory) to make effective changes in
multiple databases and systems. This centralization can substantially lower administrative
costs while materially improving enterprise security.
EUS requires that Oracle Identity Management Infrastructure must be installed. A default
installation of the Oracle Application Server Infrastructure consists of installing all
infrastructure components on the same system, including OracleAS Single Sign-On, also
known as SSO; Oracle Application Server Certificate Authority, commonly known as OCA;
and Oracle Delegated Administration Services, also referred to as DAS.
This deployment is simple, and it automatically configures SSO, OCA, and DAS as part of
the repository and OID. This deployment is adequate for setting up a quick development
or testing environment.
This deployment is all that is required for EUS. The Oracle HTTP Server, OracleAS
Containers for J2EE, also known as OC4J, and Oracle Enterprise Manager components
are always installed.
The EUS architecture is transparent to the end user. In this example, a client can submit
the same connect command, whether connecting as a database user or an enterprise
user. The enterprise user has the additional benefit of allowing the use of a shared
schema.
Graphic
The client is connected to Oracle Database using a username and password.
Oracle Database is connected to OID, and it verifies the user. OID, which is
connected to OracleAS Metadata Repository, applies roles to Oracle Database.
The user is authenticated in the following process:
The directory supplies the global roles for the user. Enterprise roles are defined in OID, and
global roles are defined in the database. The mapping from enterprise roles to global roles is in the
directory.
The directory can supply the application context. An application context supplied from OID is
called a global context.
EUS supports three authentication methods. Each authentication method has advantages
and disadvantages. These determine which authentication method is best for your EUS
implementation.
All three methods provide the following features:
the methods to support current user database links if the connection between databases is over
the secure sockets layer, commonly referred to as SSL
The three authentication methods are
password authentication
This is a password-based authentication. Password authentication requires separate
authentication for each database connection, retains users' current authentication
methods, and supports Oracle Release 7.3 (and later) clients with Oracle Database 10g
and later.
SSL authentication, and
The SSL authentication method provides strong authentication over SSL, supports single
sign-on by using SSL, and supports Oracle8i (and later) clients with Oracle Database 10g
and later.
Initial configuration may be more difficult because public key infrastructure, also called PKI,
credentials must be generated for all users. (The degree of difficulty depends on
administrators' PKI knowledge.)
Kerberos authentication
The Kerberos authentication method provides strong authentication by using Kerberos
(version 5) tickets and supports single sign-on by using Kerberos (version 5) encrypted
tickets and authenticators, and authentication forwarding. This authentication method also
supports Oracle Database 10g (and later) clients with Oracle Database 10g and later.
Initial configuration may be more difficult because Kerberos must be installed and
configured to authenticate database users.
Question
What are the features of password authentication?
Options:
1.
2.
3.
4.
Answer
Option 1: This option is correct. Password-based authentication requires separate
authentication for each database connection. This method supports Oracle
Release 7.3 and later clients with Oracle Database 10g and later.
Option 2: This option is incorrect. Kerberos authentication supports single sign-on
by using Kerberos version 5 encrypted tickets and authenticators, and
authentication forwarding.
Graphic
The OID Structure has three levels. The dc=com node is branched to cn=users,
cn=groups, dc=oracle, and oracle context. Then the cn=users node is branched to
cn=orcladmin, and dc=oracle is branched to cn=users, cn=groups, dc=us, and
oracle context. The cn=users node is branched to cn=orcladmin, and the dc=us
node is branched to cn=users, cn=groups, and oracle context. Finally, the
cn=users node is branched to cn=orcladmin.
To set up EUS, you perform the following steps:
1. install Oracle Application Server Infrastructure and
2. register the database
OID must be installed to use EUS. OID requires a metadata repository in Oracle
Database. The simplest way to meet these requirements is to use the default installation
of Oracle Application Server Infrastructure with a metadata repository from Oracle
Universal Installer.
Graphic
The Oracle Universal Installer: Select Installation Type page is open. In addition to
the Identity Management and Metadata Repository (4.01GB) option, which is
selected, the other two installation options available are Identity Management
(1.26GB) and Metadata Repository (4.01GB).
The database must be configured to use LDAP. The first choice is to use Domain Name
Services, commonly known as DNS, to perform automatic domain name lookup to locate
the directory on your network. The network administrator must have entered a DNS
Service Location Record, also known as SRV, into the domain name server.
The database administrator or DBA can use Oracle Net Configuration Assistant to create
an ldap.ora file for your ORACLE_HOME. This configuration file specifies the directory
host and port information, and the name of the identity management realm so that the
database can connect to the directory. This step is required if you are not using automatic
domain name lookup.
Graphic
The Database Configuration Assistant, Step 3 of 5 : Network Configuration page is
open. The page provides options to register the database with the directory
service.
Use the Database Configuration Assistant, also known as DBCA, to register the database
in the directory. Registration creates an entry in the directory so that the database can
bind or log in to it. The DBCA performs several configuration tasks, including creating a
wallet for the database and assigning a password for the wallet.
Graphic
In this example, the Yes, register the database option is selected, and the
appropriate user DN, password, and wallet password are entered. The No, don't
register the database is the alternate option.
In Oracle Database 11g, Enterprise Manager Database Control has pages to help you
manage the Enterprise User Security. On the database Home page, click the Server tab
to view the link to these pages in the Security section.
Graphic
In addition to the Enterprise User Security link, the Security section also contains
Users, Roles, Profiles, Audit Settings, Transparent Data Encryption, Oracle Label
Security, Virtual Private Database Policies, and Application Contexts links.
Enterprise users are created and managed in the directory. Enterprise users are mapped
to either a single schema or a shared schema that is identified in the database as a
global user.
The two types of schema are
Code
CREATE USER scott IDENTIFIED GLOBALLY AS
'cn=scott,cn=users,dc=us,dc=oracle=dc=com';
Graphic
The welcome page of Oracle Identity Management Self-Service Console is open.
1. Use the URL http://<oidhost>:<port>/oiddas to access the Oracle Identity Management SelfService Console page. The default port is 7777.
Graphic
The message displayed on successful creation of the user is the following:
Successfully created the user staylor.
You can create multiple enterprise users and a mapping object in the directory. The
mapping object informs the database about how you want to map the DN of the users to
the shared schema.
Either you can do a full DN mapping (one enterprise user to one DB schema) or you can
do a subtree mapping for example, every user containing the DN components, dc=us,
dc=oracle, dc=com to appschema.
Graphic
The Oracle Internet Directory Login > Enterprise User Security page is open. It
contains links such as Manage Enterprise Domains, Manage Databases, Manage
Enterprise Users, Manage User Defined Enterprise Groups, and OID Realm
Administration.
To create a shared schema mapping (subtree), perform the following steps:
1. click the Manage Databases link on the Enterprise User Security page of Database Control
By clicking the Manage Databases link, you create and manage user-schema mappings between
enterprise users stored in the directory and a specific database.
2. select the database and click Configure on the Manage Databases page
The selected database is orcl2.
3. click the User - Schema Mappings tab on the Configure Database : orcl2 page
By default, the General tabbed page is open. The page also has the Administrators tab.
4. click Create on the User - Schema Mappings tabbed page
The User - Schema Mappings tabbed page contains mapping details such as mapping type.
5. select the Subtree option and enter the subtree DN, and
The Create Mapping : NewMapping page is open. The entered subtree DN is
cn=Users,dc=easynomadtravel,dc=com.
6. enter the global schema to which users in the subtree will map
The database schema that is entered, in this example, is GLOBAL_SCHEMA.
Most users do not need their own schemas, and implementing shared schemas divorces
users from databases. Create one or many enterprise users in the directory. Then those
users can access the shared schema in any database where the schema mapping exists.
When a user needs a dedicated schema, creating a schema mapping object in the User
Name directory is the method for making a one-to-one mapping.
To create a subtree mapping, perform the following steps:
Graphic
The Oracle Internet Directory Login > Enterprise User Security page is open.
1. click the Manage Enterprise Users link on the Enterprise User Security page of Database
Control
By clicking the Manage Enterprise Users link, you manage user schema mapping for individual
enterprise users. Optionally manage enterprise roles, proxy permissions and label security
authorizations.
2. select the user and click Configure on the Manage Enterprise Users page
The Manage Enterprise Users page provides a table that lists the different users with details such as DN
and type. In this example, the user staylor is selected. The DN of the user is
cn=staylor,cn=users,dc=easynomadtravel,dc=com, and the account status of the user is ENABLED.
3. click the User - Schema Mappings tab on the Configure User : staylor page
By default, the General tabbed page is open. The other tabs in this page are User - Schema Mappings,
Enterprise Roles, Proxy Permissions, and Label Authorizations.
Code
$ sqlplus staylor
Password: ******
SQL> SELECT user FROM dual;
USER
----------------GUEST
By checking the external_name attribute of the USERENV context, the real user is
provided as in this code.
Code
Note
Each user accessing a current user database link must be a global user.
If you are using OID, use the Configure Domain page of Enterprise Users Security in
Oracle Enterprise Manager 11g Database Control to enable current user database links
between databases within the enterprise domain in the directory by performing the
following steps:
Graphic
The Oracle Internet Directory Login > Enterprise User Security page is open.
1. click the Manage Enterprise Domains link on the Enterprise User Security page
By clicking the Manage Enterprise Domains link, you create and configure an enterprise
domains. At least one enterprise domain is required before user schema mappings and additional
settings can be managed. A domain can contain one or more databases.
2. select a specific enterprise domain and click Configure on the Manage Enterprise Domains page
The selected enterprise domain, in this example, is OracleDefaultDomain.
3. click the Configuration tab, and
The Configure Domain : OracleDefaultDomain page is open. In this page, the Databases tabbed page is
open, by default. The other tabs available are User - Schema Mappings, Enterprise Roles, Proxy
Permissions, Configuration, and Administrators.
4. select the Enable Current User Database Links in this domain checkbox and click Ok on the
Configuration tabbed page
The Enable Current User Database Links in this domain checkbox is under the Current User Database
Links section. The other section in the Configuration tabbed page is User Authentication Types Accepted.
The user migration utility is a command-line utility invoked with the umu command, which
is used to move users from a local database model to an enterprise-user model. This
utility makes it easy to migrate local and external database users to an enterprise-user
environment in an LDAP directory. It uses the Oracle JDBC Oracle Call Interface, also
known as OCI, driver to connect to the database.
Enterprise-user administrators can select for migration any combination of the following
user subsets in a database:
administrator can read these passwords from the interface table and inform migrating
users. The umu utility will produce a listing of the allowable parameters for each phase
with umu HELP=YES.
Question
When using the user migration utility, during which step does the utility create
random passwords based on user mappings?
Options:
1.
2.
3.
4.
Answer
Option 1: This option is incorrect. During the first step of using the user migration
utility, the ORCL_GLOBAL_USR_MIGRATION_DATA interface table is populated
with information about the users from the database and the directory.
Option 2: This option is incorrect. The second step to using the user migration
utility is to verify the user information. This is an intermediate step to allow the
enterprise-user administrator to verify that the user information is correct in the
interface table before committing the changes to the database and the directory.
Option 3: This option is correct. During the third step, the utility retrieves the
information from the table and updates the directory and the database. Depending
on whether directory entries exist for migrating users, the utility creates random
passwords as needed during this phase as well.
Option 4: This option is incorrect. When you issue the umu HELP=yes command,
the utility will produce a listing of the allowable parameters for each phase.
Correct answer(s):
3. Completing the migration
If auditing is turned on, Oracle Database captures the identity of enterprise users in its
audit trails.
OID can store additional attributes for each user to help identify both authorized and
unauthorized users in both schemas:
exclusive and
When enterprise users have their own schema (exclusive schema) in the database, the
database username represents the enterprise user. The enterprise user has a one-to-one
mapping to the database user or schema.
When enterprise users access exclusive schemas in standard auditing, the USERNAME
column shows the user identity in the database, and the GLOBAL_UID column shows the
same user's global identity. In fine-grained auditing, the DB_USER column shows the user
identity in the database, and the GLOBAL_UID column shows the same user's global
identity.
shared
When enterprise users map to a shared schema in the database, the audit trails capture
both the username of the shared schema user and the identity of the actual user managed
in the directory.
When enterprise users access shared schemas in standard auditing, the USERNAME
column shows the shared schema, and the GLOBAL_UID column shows the identity of the
enterprise user. In fine-grained auditing, the DB_USER column shows the shared schema,
and the GLOBAL_UID column shows the identity of the enterprise user.
Summary
In this topic, you've learned how to set up Enterprise User Security.
Introducing Authentication
Learning Objective
In many cases, the middle-tier server authenticates and assumes the identity of the user
and is allowed to enable specific roles for the user. This is called proxy authentication.
Note
The term application or application server is used to refer to a generic application
program or application server that can be a custom application or a third-party
application. It is not an Oracle Application Server.
Although three-tier computing provides many benefits, it raises a number of new security
issues:
identifying the real user
Who is the real user? Database-level access control and auditing depends on being able
to identify the end user.
authenticating the end user to the database, and
In multitier computing, authenticating the end user to the database securely becomes a
challenge.
restricting the privileges of the middle tier
For many applications, the security model gives excessive privileges to the proxy
application user. The challenge is to allow the session created or used by the middle tier to
have privileges that are appropriate to the real end user.
Most organizations need to know the identity of the actual user who is accessing the
database. User accountability is diminished if the identity of the user cannot be traced
through all tiers of the application. If security is implemented in the application, the
possibility exists that the application could be bypassed.
End-user identification is required for these security functions:
authentication
When only the application server knows who the user is, all per-user security
enforcements must be done by the application itself.
Application-based security is very expensive.
If each application that accesses the data enforces security, then security must be
reimplemented in each and every application. It is often preferable to build security on the
data itself, with per-user accountability enforced within the database.
access control, and
Data access control at the database level is not possible when only the application knows
the user identity. The application must enforce data access control. If the application is
coded to use secure application roles, the application uses these roles to control data
access by the user.
auditing
Accountability through auditing is a basic principle of information security. Most
organizations want to know on whose behalf a transaction has been accomplished, not just
that a particular application server performed a transaction.
A system must, therefore, be able to differentiate between a user performing a transaction
and an application server performing a transaction on behalf of a user.
Auditing in three-tier systems should be tied to the issue of knowing the real user; if you
cannot preserve the user's identity through the middle tier of a three-tier application, you
cannot audit actions on behalf of the user.
Question
For authentication, access control, and auditing, most organizations need to know
the identity of the actual user who is accessing the database.
Which statements best describe auditing?
Options:
1.
When only the application server knows who the user is, the per-user security
enforcement must be done by the application itself
2.
3.
In a three-tier system, auditing cannot be done unless you can preserve the user's
identity through the middle tier
4.
If the application is coded to use secure application roles, the application uses these
roles to control data access
Answer
Option 1: This option is incorrect. When only the application server knows who
the user is, the application must perform per-user security enforcement itself. If
each application that accesses the data enforces security, then security must be
implemented in each and every application.
Option 2: This option is correct. Accountability through auditing is a basic
principle of information security. Most organizations want to know on whose behalf
a transaction has been accomplished, not just that a particular application server
performed a transaction.
Question
Which forms of proxy authentication are supported by Oracle Database?
Options:
1.
The middle-tier server authenticates itself to the database server and provides an
end user name
2.
3.
The end user is authenticated by the middle-tier server and passes a certificate
through the middle tier
4.
The user presents a credential to the application and the application authenticates
the user to the database
5.
The application can identify the user with a token of some kind
Answer
Option 1: This option is correct. In one form of proxy authentication, the middletier server authenticates itself to the database server and provides an end user
name. The end user has already authenticated to the middle-tier server. End user
identities can be maintained all the way through to the database.
Option 2: This option is correct. In another form of proxy authentication, the
database user is not authenticated by the middle-tier server. The end user identity
and database password are passed through the middle-tier server to the database
server for authentication. This is another form of the pass-through method.
Option 3: This option is correct. In another form of proxy authentication, the end
user in this case, a global user is authenticated by the middle-tier server and
passes either a distinguished name or certificate through the middle tier for
retrieving the end user name.
Option 4: This option is incorrect. In the model where the user is reauthenticated
to the database, the user presents credentials to the application this is not
necessarily the same as the database credentials and the application
authenticates the user to the database.
Option 5: This option is incorrect. In the model where the user is identified to the
database, the application can identify the user with a token of some kind. This
token maps the end user to a session.
Correct answer(s):
1. The middle-tier server authenticates itself to the database server and provides
an end user name
Summary
In this topic, you've learned how authentication works in three-tiered systems.
2. Authenticating users
For enterprise users or database users, Oracle Call Interface, also known as OCI, or Java
Database Connectivity, commonly referred to as JDBC, enables a middle tier to set up,
within a single database connection, a number of lightweight user sessions, each of
which uniquely identifies a connected user.
These lightweight sessions reduce the network overhead of creating separate network
connections from the middle tier to the database. The application can switch between
these sessions as required to process transactions on behalf of users.
The full authentication sequence from the client to the middle tier to the database occurs
in four stages:
1. the client authenticates itself to the middle tier
2. the middle tier authenticates itself to the database
3. the middle tier creates sessions for users, and
4. the database verifies the middle tier
The client authenticates to the middle tier, using whatever form of authentication the
middle tier accepts. For example, the client can authenticate to the middle tier by using a
username and password, or an X.509 certificate by means of secure sockets layer,
commonly referred to as SSL.
The middle tier creating the lightweight client sessions must first connect to the database
as a database user rather than an enterprise user.
The middle tier authenticates itself to the database, using whatever form of authentication
the database accepts. This can be a password or an authentication mechanism
supported by Oracle Advanced Security, such as a Kerberos ticket or an X.509 certificate
(SSL).
The middle tier then creates one or more sessions by using OCI or JDBC for different
types of users:
database user
If the user is a database user, the lightweight session must, as a minimum, include the
database username. If the database requires it, the session can also include a password
(which the database verifies against the password stored in the database).
The session may also include a list of database roles for the user.
enterprise user, and
If the user is an enterprise user, the lightweight session may provide different information,
depending on how the user is authenticated.
If the user is authenticated to the middle tier via SSL, the middle tier can provide the
distinguished name or DN from the user's X.509 certificate or the certificate itself in the
session.
The database uses the DN to look up the user in Oracle Internet Directory, commonly
referred to as OID. The user's roles are automatically retrieved from OID after the session
is established.
password-authenticated enterprise user
If the user is a password-authenticated enterprise user, the middle tier must provide, as a
minimum, a globally unique name for the user.
The database uses this name to look up the user in OID. If the session also provides a
password for the user, the database verifies the password against that stored in OID. The
user's roles are automatically retrieved from OID after the session is established.
If the user is a database user, the database verifies that the middle tier is privileged to
create sessions on behalf of the user, using the roles provided.
The OCISessionBegin call fails if the application server is not allowed to proxy on
behalf of the client by the administrator, or if the application server is not allowed to
activate the specified roles.
In the case of authentication with a database password, the password of the client is
passed to the middle-tier server. The middle-tier server then passes the password as an
attribute to the data server for verification. The main advantage of this is that the client
machine is not required to have the Oracle software actually installed on it.
It is not always beneficial to reauthenticate users to the database after they have been
authenticated to the middle tier.
Code
Code
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
AUTHENTICATED USING DISTINGUISHED NAME;
To pass the distinguished name of the client to the database, the application server would
call OCIAttrSet() with this pseudo interface.
Code
OCIAttrSet (
OCISession
*session_handle,
OCI_HTYPE_SESSION,
lxstp
*distinguished_name,
(ub4)
0,
OCI_ATTR_DISTINGUISHED_NAME,
OCIError *error_handle );
To authenticate the user with a certificate, use this command.
In both the DISTINGUISHED NAME and CERTIFICATE cases, the proxy has already
authenticated and is acting on behalf of a global database user.
Code
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
AUTHENTICATED USING CERTIFICATE
To pass over the entire certificate, the middle tier would use these pseudo interfaces. If
the type is not specified, the server uses its default certificate type of X.509.
Code
OCIAttrSet (
OCISession
*session_handle,
OCI_HTYPE_SESSION,
ub1
*certificate,
ub4
certificate_length,
OCI_ATTR_CERTIFICATE,
OCIError *error_handle );
Question
Which method of using proxy authentication for database users is appropriate for
application servers that are outside a trusted region?
Options:
1.
2.
With a certificate
3.
4.
Answer
Option 1: This option is correct. This method is appropriate to application servers
that are outside a trusted region (firewall). The user will provide a password that is
passed through to the database.
Option 2: This option is incorrect. The use of a certificate for authentication is
appropriate when the proxy has already authenticated to the database and acts on
behalf of a global database user that is known to the database.
Option 3: This option is incorrect. The use of a distinguished name for
authentication is appropriate when the proxy has already authenticated to the
database and acts on behalf of a global database user that is known to the
database.
Option 4: This option is incorrect. This method is sometimes appropriate for
application servers in a trusted region.
Correct answer(s):
1. With a database password
Question
2.
With a certificate
3.
4.
Answer
Option 1: This option is incorrect. When authenticating the user with a database
password, the middle tier is not assumed to be trusted. With this method, the
middle tier cannot perform any authentication.
Option 2: This option is incorrect. When using a certificate, the proxy has already
authenticated to the database and acts on behalf of a global database user who is
known to the database.
Option 3: This option is incorrect. A distinguished name is a global name used in
lieu of the password of the user being proxied for. This name is provided by the
application server when the application server connects for the user.
Option 4: This option is correct. When the middle tier authenticates the user, you
may not want to give the middle tier the user's database password. When using
this method, it is assumed that the middle tier is trusted to perform authentication.
Correct answer(s):
4. Without a database password
You can also indicate the type of certificate used to authenticate the user, using this
command.
Code
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
AUTHENTICATED USING CERTIFICATE
TYPE 'X.509' VERSION '3';
Note
Code
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
AUTHENTICATED USING CERTIFICATE
TYPE 'X.509' VERSION '3';
TYPE
The TYPE keyword is the type of certificate to be presented. If you do not specify the type,
the default is X.509.
VERSION
The VERSION keyword is the version of the certificate to be presented. If you do not
specify the version, the default is 3.
Summary
In this topic, you've learned how proxy authentication is implemented.
Code
CONNECT APPSVR[PHALL]/appsvr_pwd
CONNECT rajeev[APPSVR]/rajeev_pwd
both users are known to the database and
When both users are known to the database, the APPSVR user can connect on behalf of
PHALL. When connected, the user is PHALL and the schema is PHALL.
The application can connect as HRAPP and then initiate a session for PHALL. The APPSVR
user may have authority to enable some or all of the roles granted to PHALL.
the user is unknown to the database (enterprise user proxy)
When the user is unknown to the database, as in the case of an enterprise user with a
shared schema, the user is authenticated by the directory. The target user, APPSVR, is the
user connected to the database.
The target user is not IDENTIFIED GLOBALLY, but allows CONNECT THROUGH
ENTERPRISE USERS. When connected, the user is APPSVR. The users provide their own
enterprise user credentials, but connect as the target user with the privileges and roles of
the target user in this case, APPSVR.
In both cases, notice that the session is for the user named in the [].
Graphic
The users within the [ ] are PHALL and APPSVR.
Code
CONNECT APPSVR[PHALL]/appsvr_pwd
CONNECT rajeev[APPSVR]/rajeev_pwd
In Oracle Database, the enterprise user proxy is available to allow you to use Enterprise
User Security, also known as EUS, in combination with existing applications that use the
one big-application user model.
All the users have been connecting as APPSVR, and now they have been given
enterpriser user credentials in the directory. They can continue to use the application with
a proxy connect, as in this example. The users provide their EUS credentials and the
target user, and connect to the database as the target user.
Code
CONNECT george[APPSVR]/george_pwd
Enterprise users can be individually granted permissions to proxy as local database
users. Enterprise user proxy permissions are created and stored in Oracle Internet
Directory.
A permission allows one or more enterprise users or groups to proxy as a target database
user. By default, domain administrators manage proxy permissions in the directory for an
enterprise domain. These permissions are configured and managed using Enterprise
Manager Enterprise User Security pages.
In most cases, enterprise users, such as george, are unknown to the database. They
are called proxy users. The mapping of a proxy user to a database user is called a proxy
permission. The user making the connection, APPSVR, is called the target user, is a
database user, and is not identified globally.
Consider the case where the PARTS application connects to the database as the
PARTS_GUEST user and creates a connection pool. The PARTS_GUEST user has
privileges to access the PARTS_APP schema. These privileges may be granted through
roles granted to PARTS_GUEST. PARTS_GUEST is not a global user.
JIM and RAJEEV are enterprise users created in the directory. They are mapped to a
shared schema. Any shared schema is adequate because the shared schema is not
used.
Any user that connects using the PARTS_GUEST proxy schema is granted the roles
granted to the PARTS_GUEST user. Every user connecting to the PARTS_GUEST schema
receives all the roles and privileges granted to PARTS_GUEST by default. The application
may enable secure application roles to allow RAJEEV and JIM the individual access
required.
Graphic
Rajeev and Jim are connected to the shared schema, PARTS_DB.
Rajeev is connected through the following command:
CONNECT RAJEEV[PARTS_GUEST]/pwd
And Jim is connected through the following command:
CONNECT JIM[PARTS_GUEST]/pwd
The DBA still controls which database users can be proxied. The DBA changes the proxy
grant with this command.
Only local database schemas can be granted CONNECT THOUGH ENTERPRISE USERS.
Only users designated as such can be added as a database target user to a proxy
permission in the directory.
Code
ALTER USER parts_guest GRANT CONNECT THOUGH ENTERPRISE
USERS;
You can create an enterprise user proxy by performing the following steps:
1. create a named proxy permission, PROXY1 in the directory
2. assign enterprise users JIM and RAJEEV to the proxy permission
3. assign a database target user, PARTS_GUEST, to the proxy permission, and
4. change PARTS_GUEST in the database with this command
The command used to change the database is the following:
ALTER USER PARTS_GUEST CONNECT THROUGH ENTERPRISE USERS
When JIM or RAJEEV want to create a session, the application issues an OCI call
equivalent to this SQL command.
The PARTS_DB database contacts the directory to authenticate the enterprise users. The
roles are assigned based on the roles assigned to the target database user,
PARTS_GUEST.
Code
CONNECT JIM[PARTS_GUEST]/pwd@parts_db
This statement takes away the right of the user PHALL to connect through the proxy user
APPSVR.
You cannot specify the AUTHENTICATED USING or AUTHENTICATION REQUIRED clause
as part of a REVOKE CONNECT THROUGH PROXY clause.
Code
ALTER USER phall REVOKE CONNECT THROUGH APPSVR;
depending on the roles assigned to the user in the application. These roles may be secure
application roles, which can be enabled only through a secure package.
Applications can reset the client identifier, and thus reuse the session for a different user,
enabling high performance. For OCI-based connections, the call to change
CLIENT_IDENTIFIER is combined with other OCI calls to further enhance performance.
An application-user proxy is available in thin JDBC, thick JDBC, and OCI, and provides
the benefits of connection pooling without the overhead of separate user sessions (even
lightweight ones).
Note
V$SESSION.CLIENT_IDENTIFIER and
V$SESSION_CONNECT_INFO.AUTHENTICATION_TYPE can provide additional
information about the end user's identity and authentication, for auditing purposes.
Code
PROXY
-------HRUSER
APPSVR
CLIENT
-------PHALL
PHALL
AUTH
---NO
NO
AUTHORIZATION_CONSTRAINT
-----------------------------PROXY MAY ACTIVATE ROLE
NO CLIENT ROLES MAY BE
ACTIVATED
HRUSER
PFAY
YES
The USER_PROXIES view contains connections that the current user is allowed to proxy.
The DBA_PROXIES and USER_PROXIES views contain the following columns:
Code
SQL> SELECT proxy, client, authentication,
2
authorization_constraint
3 FROM dba_proxies
PROXY
-------HRUSER
APPSVR
CLIENT
-------PHALL
PHALL
AUTH
---NO
NO
AUTHORIZATION_CONSTRAINT
-----------------------------PROXY MAY ACTIVATE ROLE
NO CLIENT ROLES MAY BE
ACTIVATED
HRUSER
PFAY
YES
ACTIVATED
HRUSER PFAY YES PROXY MAY ACTIVATE ALL CLIENT
ROLES
CLIENT name of the client user on whose behalf the proxy user can act.
Code
SQL> SELECT proxy, client, authentication,
2
authorization_constraint
3 FROM dba_proxies
The DBA_PROXIES also contains ROLE and PROXY_AUTHORITY columns. The ROLE
column contains the role referenced in the authorization constraint.
Code
SQL> SELECT proxy, client, authentication,
2
authorization_constraint
3 FROM dba_proxies
PROXY
-------HRUSER
APPSVR
CLIENT
-------PHALL
PHALL
AUTH
---NO
NO
AUTHORIZATION_CONSTRAINT
-----------------------------PROXY MAY ACTIVATE ROLE
NO CLIENT ROLES MAY BE
ACTIVATED
HRUSER
PFAY
YES
Question
Which data dictionary view contains information about all proxy connections in the
system?
Options:
1.
DBA_PROXIES
2.
USER_PROXIES
3.
PROXY_USERS
4.
V$SESSION
Answer
Option 1: This option is correct. The DBA_PROXIES view displays information
about all proxy connections in the system. Its columns include PROXY,
CONNECTION, and ROLE.
Option 2: This option is incorrect. The USER_PROXIES view displays information
about connections that the current user is allowed to proxy.
Option 3: This option is incorrect. The PROXY_USERS view describes users who
can assume the identity of other users.
Option 4: This option is incorrect. The V$SESSION view displays information
about network connections for all current sessions.
Correct answer(s):
1. DBA_PROXIES
The V$SESSION_CONNECT_INFO view displays information about network connections
for the current session.
The SID column can be used to join this view with V$SESSION. There can be multiple
rows returned for each session. This is a banner for one session started by OSUSER
oracle.
Code
SQL> select SID, AUTHENTICATION_TYPE,
2
OSUSER, NETWORK_SERVICE_BANNER
3 from v$session_connect_info where SID = 148;
11.1.0.6.0 -
Production
148 DATABASE
Linux:
Version 11.1.0.6.0 - Production
Code
SQL> select SID, AUTHENTICATION_TYPE,
2
OSUSER, NETWORK_SERVICE_BANNER
3 from v$session_connect_info where SID = 148;
SI
D AUTHENTICA OSUSER NETWORK_SERVICE_BANNER
----- ---------- -------------------------------------------148 DATABASE
oracle TCP/IP NT Protocol Adapter for
Linux:
Version 11.1.0.6.0 - Production
148 DATABASE
11.1.0.6.0 Production
148 DATABASE
Linux:
Version 11.1.0.6.0 - Production
SID
The SID column contains the session identifier.
AUTHENTICA
The AUTHENTICATION_TYPE column stores values on how the user is authenticated. The
values are DATABASE username and password, OS external operating system,
NETWORK network or Oracle Advanced Security, also known as ASO, and PROXY OCI
proxy connection.
OSUSER
The OSUSER column contains the external username for the database user.
NETWORK_SERVICE_BANNER
The NETWORK_SERVICE_BANNER column contains product banners for each Oracle Net
Service used for this connection, with one row per banner.
Question
Which V$SESSION_CONNECT_INFO column would you query to determine the
external OS and OCI proxy connection?
Options:
1.
SID
2.
AUTHENTICATION_TYPE
3.
OSUSER
4.
NETWORK_SERVICE_BANNER
Answer
Option 1: This option is incorrect. The SID column contains the session identifier.
Option 2: This option is correct. The AUTHENTICATION_TYPE column stores
values on how the user is authenticated. The values are in DATABASE, OS,
NETWORK, and PROXY.
Option 3: This option is incorrect. The OSUSER column contains the external
username for the database user.
Option 4: This option is incorrect. The NETWORK_SERVICE_BANNER column
contains product banners for each Oracle Net Service used for the connection,
with one row per banner.
Correct answer(s):
2. AUTHENTICATION_TYPE
You can use the proxy authentication features of the database to audit the actions that
the middle tier performs on behalf of a user in two situations:
Code
AUDIT SELECT TABLE
ON employees
BY hrappserver ON BEHALF OF phall;
Code
AUDIT SELECT TABLE
ON employees;
For audit actions taken on behalf of the real user, you cannot audit CONNECT ON BEHALF
OF DN because the distinguished name is not known to the database. However, if the
user accesses a shared schema (for example, APPUSER), you can audit CONNECT ON
BEHALF OF APPUSER.
With enterpriser user proxy, the distinguished name of the enterprise user is available in
the PROXY_ENTERPRISE_IDENTITY attribute of the USERENV context. With a finegrained auditing also known as FGA event handler, the
PROXY_ENTERPRISE_IDENTITY attribute can be captured from the USERENV context.
Question
Which statement represents an example of auditing on behalf of any user?
Options:
1.
2.
3.
4.
Answer
Option 1: This option is incorrect. This statement is used to enable auditing for
SELECTs on the EMPLOYEES table that HRAPPSERVER initiates for the user
PHALL.
Option 2: This option is correct. You can enable auditing on behalf of multiple
users connecting through a middle tier using this statement.
Option 3: This option is incorrect. To capture SELECTs against the EMPLOYEES
table from clients connecting directly to the database, you can use this statement.
Option 4: This option is incorrect. To capture SELECTs against the EMPLOYEES
table from the HR and OE users, you can use this statement.
Correct answer(s):
2. AUDIT SELECT TABLE ON employees BY hrappserver ON BEHALF OF ANY;
The DBA_STMT_AUDIT_OPTS view describes the current system auditing options across
the system and by the user.
The following columns are related to auditing the actions of the proxy user:
USER_NAME and
If auditing user actions, the username is recorded. If access by a proxy on behalf of a
client is being audited, ANY CLIENT is recorded. Otherwise, NULL is recorded for systemwide auditing.
PROXY_NAME
The name of the proxy user who is performing an operation for the client is recorded. If the
client is performing the operation directly, NULL is recorded.
Other columns that are not related to proxy users are not listed.
The DBA_AUDIT_TRAIL view lists all audit-trail entries. The USER_AUDIT_TRAIL view
contains all audit-trail entries related to the current user.
The COMMENT_TEXT column can indicate how the user has been authenticated.
The following are the authentication methods:
DATABASE
Authentication has been done by the password.
NETWORK
Authentication has been done by Oracle Net Services or Oracle Advanced Security.
PROXY, and
The client has been authenticated by another user; the name of the proxy user follows the
method type.
EXTERNAL NAME
The distinguished name is provided in addition to other comments if the user is an
enterprise user.
Summary
In this topic, you've learned how to manage and audit users authenticated by proxy
authentication.
Exercise overview
You want to make a one-to-one association between an enterprise user and a database
schema. Then you want to test the connection and view the available user identity
information. You have created a shared schema and want to enable all enterprise users
to connect to the shared schema for your database. You also want to create and
configure an enterprise proxy user.
In this exercise, you're required to associate an enterprise user with a database schema,
test the connection, enable the use of a shared schema, and create a proxy permission.
This involves the following tasks:
Steps list
Instructions
1. Click Manage Enterprise Users
2. Click Go
3. Select the aking radio button and click Configure
4. Click the User - Schema Mappings tab
5. Click Create
6. Type AKING in the Schema text box and click Continue
7. Click OK
Steps list
Instructions
1. Type show user and press Enter
2. Type SELECT SYS_CONTEXT('USERENV', 'EXTERNAL_NAME') and press Enter
3. Type FROM DUAL; and press Enter
4. Type SELECT SYS_CONTEXT('USERENV', 'SESSION_USER') and press Enter
5. Type FROM DUAL; and press Enter
Steps list
Instructions
1. Click Manage Databases
2. Ensure orcl2 is selected and click Configure
3. Click the User - Schema Mappings tab
4. Click Create
5. Select the Subtree radio button
6. Type cn=Users,dc=easynomadtravel,dc=com in the associated text box
7. Type global_schema in the Schema text box and click Continue
8. Click OK
Steps list
Instructions
1. Click Create
2. Type hr_proxy in the Name text box and click Continue
3. Ensure hr_proxy is selected and click Edit
4. Click Add
5. Type system in the User Name text box, type oracle in the Password text box, and click Go
6. Select the HR_USER checkbox and click Select
7. Click the Grantees tab
8. Click Add
9. Type LPARKS in the Name text box and click Go
10. Select the cn=LPARKS,cn=users, dc=easynomadtravel,dc=com checkbox and click Select
11. Click Continue
12. Click OK