Using Enterprise User Security

Learning Objectives

After completing this topic, you should be able to

recognize how to set up Enterprise User Security

recognize how to work with Enterprise User Security

1. Setting up Enterprise User Security

A basic security requirement is that you must know your users. You must identify them
before you can determine their privileges and access rights, so that you can audit their
actions on the data. To identify users, you create and audit enterprise users authenticated
through Oracle Internet Directory, abbreviated as OID.

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 user presents a username and password (or other credentials).

The directory returns the authorization token to the database.

The schema is mapped from the OID information.

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:

centralized user and credential management

a user identity that can be used in two-tier or multitier applications, and

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.

It retains users' current authentication methods

2.

It supports single sign-on using encrypted tickets

3.

It requires separate authentication for each database connection

4.

It provides strong authentication over SSL

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.

Option 3: This option is correct. Password-based authentication requires separate

authentication for each database connection. This method provides centralized
user and credential management.
Option 4: This option is incorrect. SSL authentication provides strong
authentication over SSL and also supports single sign-on using SSL.
Correct answer(s):
1. It retains users' current authentication methods
3. It requires separate authentication for each database connection
OID has a tree structure following the LDAP standards. At each level, certain nodes are
repeated. In this example, there is an orcladmin user defined at each level. There is an
orcladmin that is the administrator of the entire structure and is defined at the highest
level. Each level is called a realm.
There is also a cn=orcladmin, cn=users, dc=com. The cn=orcladmin,
cn=users, dc=us, dc=oracle, dc=com is the administrator that is used to manage
the us.oracle.com realm.

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.

2. Creating enterprise users

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';

CREATE USER appschema IDENTIFIED GLOBALLY;

exclusive and
Creating a global user who is authenticated by a password and authorized by the
enterprise directory service is represented by this statement.
In this case, assume scott is a schema in the database mapped to a single enterprise
user, cn=scott, cn=users, dc=us, dc=oracle=dc=com.
The scott enterprise user must be created in the directory, and a global user scott must
be created in every database that the enterprise user scott accesses.
shared
With this statement, the application schema is created in the database. The directory maps
one or more enterprise users to this shared schema. A shared schema allows multiple
enterprise users to access a single schema in the database.
This type of enterprise user is authenticated by SSL, Kerberos, or passwords, is created
only in the directory, and connects to a shared schema.
You can create enterprise users in the directory by using the Oracle Identity Management
Provisioning console. This function resides in the Oracle Identity Management SelfService Console.
To create an enterprise user, perform the following steps:

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.

In the example, the URL used is the following:

http://localhost2.easynomadtravel.com:7779/oiddas/
2. Log in and enter user credentials of a user that has privileges to create users such as orcladmin.
The Single Sign-On user name orcladmin and password is entered.
3. Back on the Oracle Identity Management Self-Service Console page, click Directory.
The other tabs in this page are Home, My Profile, and Configuration.
4. On the Users page, click Create.
The Directory tabbed page is open. The Directory tabbed page provides the Users, Groups, Services,
and Applications tabs. The Users tabbed page is open. The Users page contains user details, such as
user ID, email address, first name, and last name, in a tabular format.
5. On the Create User page, enter the basic information and click Submit.
In the Basic Information section of the Create User page, user details such as first name, middle name,
last name, user ID, and password are entered in the corresponding fields.
In the example, the user Scott Taylor is created. He has a user ID of staylor. This is the
name Scott will use when he attempts to connect. His distinguished name or DN is
cn=Scott Taylor, cn=users, dc=us, dc=oracle, dc=com because of the user
creation base that was set in the directory configuration.

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.

4. click Create on the User - Schema Mappings tabbed page

The User - Schema Mappings tabbed page contains mapping details such as the mapping type, schema,
and scope name.
5. select the User Name option, and
The DN of the user is cn=staylor,cn=users, dc=easynomadtravel,dc=com.
6. enter the global schema to which users in the subtree will map
The schema to which the enterprise user can connect is SCOTT.
It is a useful technique to move database users who currently have their own schema in
the database to enterprise users:
1. migrate the database users to the directory
2. alter each schema to be identified globally, and
3. create a mapping for each user to the corresponding database schema

3. Migrating and auditing users

The enterprise user who is mapped to a shared schema is unknown to the database.
When OID is used to authenticate the user to the database, the real name of the
enterprise user can be found in the login session by using the SYS_CONTEXT function.
This name is held in the external_name attribute of the USERENV context.
The shared schema is provided as in this code.

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

SQL> select sys_context ('userenv' , 'external_name') from

dual;
SYS_CONTEXT('USERENV','EXTERNAL_NAME')
------------------------------------------------------cn=Scott Taylor,cn=Users,dc=us,dc=oracle,dc=com
Current user database links require SSL-enabled network connections between the
databases. Before you can enable the current user database links, you must enable SSL,
create Oracle wallets, and obtain PKI credentials for all databases involved.
OID and Oracle Identity Management Metadata Repository are not required, but some
form of global authentication is required (SSL or Kerberos).

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:

list of users specified on the command line or in a file

all external users, or

all local users

In addition, enterprise-user administrators can specify values for utility parameters that
determine how the users are migrated, such as where to put the migrated users in the
LDAP directory tree, and mapping a user with multiple accounts on various databases to
a single directory user entry.
The user is migrated in the following process:
preparing for the migration (phase one)
In the first part of the migration process, the ORCL_GLOBAL_USR_MIGRATION_DATA
interface table is populated with information about the users from the database and the
directory. The command-line options that are used determine what information populates
this table.
verifying user information (intermediate phase), and
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.
completing the migration (phase two)
After the user information in the interface table is checked, in phase two, 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. If migrating users are being mapped to newly created directory
entries, the utility generates random passwords, which are used as credentials for both
the database and the directory. If migrating users are being mapped to existing directory
entries with unset database passwords, the utility generates random database passwords
only.
In either case, after generating the required random passwords, the utility stores them in
the DBPASSWORD and DIRPASSWORD interface table columns. The enterprise-user

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.

Preparing the migration

2.

Verifying user information

3.

Completing the migration

4.

Listing allowable parameters

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

After completing this topic, you should be able to

recognize how authentication works in three tiered systems

1. Identifying the user

A basic security requirement is that you must know your users. You must identify them
before you can determine their privileges and access rights, so that you can audit their
actions on the data.
Knowing the end user allows you to specify users who are allowed to connect through a
middle-tier server.

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.

Most organizations want to know on whose behalf a transaction has been

accomplished

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.

Option 3: This option is correct. 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.
Option 4: This option is incorrect. 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.
Correct answer(s):
2. Most organizations want to know on whose behalf a transaction has been
accomplished
3. In a three-tier system, auditing cannot be done unless you can preserve the
user's identity through the middle tier

2. Authenticating the user

There are several implementations and variations of three-tier authentication methods.
Most of these methods can be grouped into two categories:
pass through and
In the pass-through category, the user is unknown to the application. The application would
query the user for credentials and pass the response to the database for authentication.
This is a traditional model requiring each user to have a database schema and login. This
method can be moved to an enterprise-user model with no changes to the application.
The application is not responsible for authentication, authorization, or access control.
Auditing can be handled by the database because the real user is obvious. This method is
no different from the client/server model, where the user connects directly to the database.
one big-application user
In the one big-application user category, the user is unknown to the database. In this
model, the application is responsible for authentication, authorization, and access control.
All end users present their credentials to the application, and the application user connects
to the database. Often, the application user is the application owner with all privileges to all
application objects.
This model is easy to code, but violates the principle of least privilege.
When the authentication process is determined by the application, it can use a
Lightweight Directory Access Protocol also known as LDAP directory, local files, or
some other method to validate the user. The application can make use of roles, enabling

and disabling roles to control the access.

Unless the application keeps some kind of mapping, end-user auditing can be difficult or
impossible.
Authentication is also implemented through other methods:

the user is reauthenticated to the database

the user is identified to the database, and

the user is proxied

When reauthenticating the user to the database, the user presents a credential to the
application (not necessarily the same as the database credentials), and the application
authenticates the user to the database.
This model requires a secure method of storing user credentials in the middle tier. Using
LDAP directory services is one of the few methods that can store credentials securely.
Single sign-on is a secure solution for this model.
The application can identify the user with a token of some kind. This token maps the end
user to a session. The end user is still unknown to the database, but end-user auditing is
possible.
The application uses the DBMS_APPLICATION_INFO.SET_CLIENT_IDENTIFIER
procedure or sets CLIENT_IDENTIFIER with the DBMS_SESSION.SET_IDENTIFIER
procedure in conjunction with the application context to make this identification.
Oracle Database supports three forms of proxy authentication:
middle tier to database
The middle-tier 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.
end user to database, and
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.
end user to the middle tier
The end user in this case, a global user is authenticated by the middle-tier server and
passes either a distinguished name, also known as DN, or certificate through the middle
tier for retrieving the end user name.

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.

The database user is not authenticated by the middle-tier server

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

2. The database user is not authenticated by the middle-tier server

3. The end user is authenticated by the middle-tier server and passes a certificate
through the middle tier

3. Reauthenticating the user

To meet the requirements of database-level security, every user the application server,
end users, and proxy users must be identified to the database. Reauthentication occurs
when a user is identified to the middle tier and then is identified again to the database.
In client/server systems, authentication tends to be straightforward the client
authenticates to the server.
In three-tier systems, authentication is more difficult because there are several potential
types of authentication:
middle tier to database
Because the middle tier usually initiates a connection to a database to retrieve data,
whether on its own behalf or on behalf of the user, this connection clearly must be
authenticated. In fact, Oracle Database does not allow unauthenticated connections. The
middle tier-to-database authentication can also be mutual if you are using a protocol that
supports this, such as secure sockets layer, also known as SSL.
If you are using connection pooling, the application server authenticates to the database
when it builds the pool during startup, before there are any end users.
end user to middle tier, and
If a system is to conform to basic security principles, client authentication to the middle tier
is required. This is because the middle tier is the first gateway to useful information and
services that the user can access.
Such authentication can be mutual by using SSL that is, the middle tier authenticates to
the client just as the client authenticates to the middle tier.
end-user reauthentication through the middle tier to the database
There are many methods used for end-user authentication through the middle tier. Enduser reauthentication from the middle tier to the database is problematic in three-tier
systems.
The following problems can occur in three-tier systems:
username mismatch
The username may not be the same on the middle tier and the database. In this case,
users may need to remember and reenter a username and password, which the middle tier
uses to connect on their behalf.

improper use of passwords

For the end user to reauthenticate to the database, the middle tier either needs to ask the
user for a password or retrieve a password for the user and use that to authenticate the
user.
Both approaches involve security risks because the middle tier is trusted to handle the
user's password properly, and not to allow it to be used improperly.
network overhead
Two sets of authentication handshakes per user involve considerable network overhead.
absence of audit at the database level
The database may simply accept that the middle tier has performed proper authentication.
That is, the database accepts the identity of the real users without requiring the real users
to authenticate themselves. This method hides the real user from the database, so auditing
at the database level is not possible.
absence of end-user reauthentication, and
For some authentication protocols, end-user reauthentication is just not possible.
For example, many browsers and application servers support the SSL protocol. However,
SSL is a point-to-point protocol, and not an end-to-end protocol. It cannot be used to
reauthenticate a browser client through the middle tier to the database.
insecure mapping of username
The middle tier may map the username provided during the middle-tier authentication to a
database username. Where this mapping is held is the problem. Does the mapping include
passwords? Is the mapping secure?
One solution is for the middle tier to use username mapping through an LDAP-compliant
directory service, such as Oracle Internet Directory, commonly referred to as OID.
One case where reauthentication does not involve trusting the middle tier is when a
middle tier downloads an applet to a client, and the client connects directly to the
database via the applet.
In this case, the application server serves the application (applet) to the user and has no
part in further authentication of the user. This is considered a pass-through method.
The end user prefers to have a single authentication because it simplifies the process.
Also, when the client must remember multiple account names and passwords, it
increases the chances that the end user writes this information down, making the
application less secure.
The middle tier is restricted to two levels of privileges:

high privileges and

A common application security model uses one application user to perform all connections
to the database, and all user requests through the application are performed as the
application user. These all-privileged middle tiers, such as transaction processing, also
known as TP, monitors, can perform all actions for all users.
In this architecture, the middle tier connects to the database as the same user for all
application users. It therefore needs to have all privileges that application users need to do
their jobs. This is also called the one big-application user model. This security model does
not provide defense in depth. If the middle tier is compromised, all the application data is
exposed.
limited privileges
More desirable is a limited trust model, in which the identity of the real client is known to
the data server, and the application server (or other middle tier) has a restricted privilege
set. A more secure model limits the privileges granted to the application. It allows the
application to connect on behalf of certain users only, and allows it to assume only certain
roles on behalf of the user.
For example, many organizations would prefer that users have different privileges,
depending on where they are connecting from. Users connecting to a web server or an
application server on the firewall may be able to access only a minimal set of data,
whereas users connecting to a server within the enterprise may be able to exercise all
privileges that they are otherwise entitled to have.

Summary
In this topic, you've learned how authentication works in three-tiered systems.

Proxy Authentication Solutions

Learning Objective

After completing this topic, you should be able to

recognize proxy authentication solutions

1. Using proxy authentication solutions

Proxy authentication is implemented in two ways, depending on the identity of the end
user. The first is for the database user and the enterprise user. Both these users are
identified to the database. The second is for the end user who is known only to the
application.

Implementing proxy authentication provides the following features:

passes through the identity of the real user

reauthenticates the real user

supports application user models

limits the privileges of the middle tier, and

audits actions taken on behalf of the real user

Many organizations want to know who the user is through all the tiers of an application,
without sacrificing the benefits of a middle tier. Oracle Database supports proxy
authentication for preserving the user identity through the middle tier of an application.
The real user can be identified in the following situations:

database users have a database account that maintains their identity

enterprise-user identities are maintained in Oracle Internet Directory, commonly referred to as
OID, and are identified by using a distinguished name or DN, and
application users are known to the application, but not to the database
Database and enterprise users can be reauthenticated to the database after connecting
to the application server.
Database users can supply a password that is passed to the database. Enterprise users
can be authenticated to the database by a password, certificate, or Kerberos token. End
users unknown to the database cannot be authenticated to the database.
Many applications use session pooling to set up a number of sessions that are owned by
the application user. These sessions are reused by multiple end users. These end users
who are not known to the database are authenticated to the middle tier of an application.
Oracle Database supports the application-user proxy for these types of applications. The
application can identify the user with an arbitrary identifier in Oracle Database, and this
identifier can be audited. The application is responsible for maintaining a mapping
between the identifier and the end user.
The Oracle Database proxy feature enables you to limit the middle tier so that it can
connect on behalf of certain database users only, using only specific database roles.
The proxy authentication features of Oracle Database enable you to audit actions that a
middle tier performs on behalf of a user.

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.

3. Database and enterprise users

Middle-tier authentication allows one Java Database Connectivity, commonly referred to
as JDBC, connection (session) to act as a proxy for other JDBC connections. Use the
CONNECT THROUGH clause in the ALTER USER command to indicate that the user is
authenticated through a middle tier.
Database users can be authenticated using two methods:

Code

ALTER USER phall

GRANT CONNECT
THROUGH APPSVR;

ALTER USER phall

GRANT CONNECT
THROUGH APPSVR
AUTHENTICATION REQUIRED PASSWORD;
without a database password and
When the middle tier authenticates the user, you may not want to give the middle tier the
user's database password. If the middle tier does not know the password, the user can be
authenticated without a database password, using this command.
The user can connect as PHALL by using the already authenticated credentials of the
middle-tier APPSVR. This method assumes that the middle tier is trusted to perform the
authentication.
The created session behaves as if PHALL has been connected normally; PHALL does not
have to divulge the password to the middle tier. The proxy session accesses the schema
of PHALL. This method is sometimes appropriate for application servers in a trusted
region.
with a database password
To authenticate the user with a password, use this command. The Oracle instance expects
the proxy to authenticate the user, unless you specify the AUTHENTICATION REQUIRED
clause. The AUTHENTICATION REQUIRED clause is relevant only as part of a GRANT
CONNECT THROUGH PROXY clause.
In this method, the middle tier is not assumed to be trusted. The middle tier may not
perform any authentication. The user authenticates to the database by providing the
database password. 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.
For enterprise users, you can authenticate with a distinguished name and a certificate. In
both the DISTINGUISHED NAME and CERTIFICATE cases, the proxy has already been
authenticated to the database and acts on behalf of a global database user who is known
to the database. The application server is responsible for the authentication in both cases
and is trusted by the database.
To authenticate the user with a distinguished name, use this command. The distinguished
name is a global name in lieu of the password of the user being proxied for.

For example, CN=phall, OU=americas, O=oracle, L=redwoodshores, ST=ca,

C=us can be the distinguished name. The distinguished name is provided by the
application server when the application server connects for the user.
The distinguished name may initially be provided by the user to the application server, or
the application server may retrieve the distinguished name from a Lightweight Directory
Access Protocol, also known as LDAP, directory.

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.

With a database password

2.

With a certificate

3.

With a distinguished name

4.

Without a database password

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

In which method of using proxy authentication for database users is it assumed

that the middle tier is trusted to perform authentication?
Options:
1.

With a database password

2.

With a certificate

3.

With a distinguished name

4.

Without a database password

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

The AUTHENTICATED USING CERTIFICATE clause is discouraged, and may not

be supported in future versions.
This command contains two additional keywords.

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.

Enterprise User Proxy

Learning Objectives

After completing this topic, you should be able to

manage users authenticated by proxy authentication

recognize how to audit users with proxy authentication

1. Using an enterprise user proxy

Proxy access through SQL*Plus is possible when

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;

Many applications use session pooling to set up a number of sessions to be reused by

multiple users. In this context, the end users who are not known to the database are
authenticated to the middle tier of an application. Oracle Database supports an
application-user proxy for these types of applications.
In this model, the middle tier passes a client identifier to the database on session
establishment. (The client identifier can actually be anything that represents an end user
connecting to the middle tier for example, the end-user ID or an IP address.)
The client identifier, representing the end user, is available in the user-session information
and can also be accessed via an application context (via the USERENV naming context).
In this way, applications can set up and reuse sessions, while still being able to keep
track of the end user in the session.
The full authentication sequence from the client to the middle tier to the database occurs
in four steps:
the middle tier authenticates to the database server
During startup, the middle tier authenticates itself to the database server and creates a
connection pool. The method of authenticating to the database 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 end user authenticates to the middle tier
The end user authenticates to the middle tier, using whatever form of authentication that
the middle tier accepts.
For example, the user can authenticate to the middle tier by using an X.509 certificate by
means of secure sockets layer, also known as SSL, or the user can authenticate to the
middle tier by using a username and password stored in the application.
the middle tier allocates a session for the end user, and
The middle tier uses an available connection from its connection pool to create a session
for the end user, and uses JDBC or OCI calls to pass the end-user identifier to the
database.
the middle tier sets roles for the end user
Depending on the information stored in the application, the middle tier can also set roles
for the end user.
For example, if the application has multiple roles, you can create database roles that
match the application roles, assign appropriate privileges to the database roles, and assign
these roles to the application-server user, but disable the roles.
When the user starts a session, the application server enables the appropriate roles,

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.

2. Defining data dictionary views

There are five data dictionary views for proxy authentication:
USER_PROXIES
The USER_PROXIES view displays information about connections that the current user is
allowed to proxy. This view does not display the PROXY column.
PROXY_USERS
The PROXY_USERS view describes users who can assume the identity of other users.
V$SESSION_CONNECT_INFO
The V$SESSION_CONNECT_INFO view displays information about network connections
for all current sessions.
V$SESSION, and
The V$SESSION columns (PROGRAM and MODULE) have a value of proxy-user... when
the session is being proxied.
DBA_PROXIES
The DBA_PROXIES view displays information about all proxy connections.
The DBA_PROXIES view displays information about all proxy connections in the system.
In the example, HRUSER may activate any or all roles granted to PFAY. HRUSER may
activate only a specified role for PHALL. APPSVR may not activate any roles for PHALL.

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

PROXY MAY ACTIVATE ALL CLIENT

ROLES

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

PROXY MAY ACTIVATE ALL CLIENT

ROLES

PROXY proxy username, in DBA_PROXIES only.

Code
SQL> SELECT proxy, client, authentication,
2
authorization_constraint
3 FROM dba_proxies

PROXY CLIENT AUTH AUTHORIZATION_CONSTRAINT

-------- -------- ---- -----------------------------HRUSER PHALL NO PROXY MAY ACTIVATE ROLE
APPSVR PHALL NO NO CLIENT ROLES MAY BE

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

PROXY CLIENT AUTH AUTHORIZATION_CONSTRAINT

-------- -------- ---- -----------------------------HRUSER PHALL NO PROXY MAY ACTIVATE ROLE
APPSVR PHALL NO NO CLIENT ROLES MAY BE
ACTIVATED
HRUSER PFAY YES PROXY MAY ACTIVATE ALL CLIENT
ROLES

AUTHENTICATION credential passed by the proxy for the client.

Code
SQL> SELECT proxy, client, authentication,
2
authorization_constraint
3 FROM dba_proxies

PROXY CLIENT AUTH AUTHORIZATION_CONSTRAINT

-------- -------- ---- -----------------------------HRUSER PHALL NO PROXY MAY ACTIVATE ROLE
APPSVR PHALL NO NO CLIENT ROLES MAY BE
ACTIVATED
HRUSER PFAY YES PROXY MAY ACTIVATE ALL CLIENT
ROLES

AUTHORIZATION_CONSTRAINT authority of the proxy to exercise roles on the client's behalf.

The value PROXY MAY ACTIVATE ROLES indicates that only selected roles may be activated.
Code

SQL> SELECT proxy, client, authentication,

2
authorization_constraint
3 FROM dba_proxies

PROXY CLIENT AUTH AUTHORIZATION_CONSTRAINT

-------- -------- ---- -----------------------------HRUSER PHALL NO PROXY MAY ACTIVATE ROLE
APPSVR PHALL NO NO CLIENT ROLES MAY BE
ACTIVATED
HRUSER PFAY YES PROXY MAY ACTIVATE ALL CLIENT
ROLES

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

PROXY MAY ACTIVATE ALL CLIENT

ROLES

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;

SID AUTHENTICA OSUSER NETWORK_SERVICE_BANNER

----- ---------- -------------------------------------------148 DATABASE
oracle TCP/IP NT Protocol Adapter for
Linux:
Version 11.1.0.6.0 - Production
148 DATABASE

oracle Oracle Advanced Security: encryption

service for Linux: Version

11.1.0.6.0 -

Production
148 DATABASE

oracle Oracle Advanced Security:

crypto-checksumming service for

Linux:
Version 11.1.0.6.0 - Production

The V$SESSION_CONNECT_INFO view contains four columns.

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

oracle Oracle Advanced Security: encryption

service for Linux: Version

11.1.0.6.0 Production
148 DATABASE

oracle Oracle Advanced Security:

crypto-checksumming service for

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

3. Auditing user actions

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;

AUDIT SELECT TABLE

ON employees
BY hrappserver
ON BEHALF OF ANY;
auditing on behalf of a specific user and
For example, suppose an application server HRAPPSERVER creates multiple lightweight
sessions for the PHALL user. You can enable auditing for SELECTs on the EMPLOYEES
table that HRAPPSERVER initiates for PHALL.
auditing on behalf of any user
Alternatively, you can enable auditing on behalf of multiple users connecting through a
middle tier.
The ON BEHALF OF auditing option audits only the SELECT statements being initiated by
HRAPPSERVER on behalf of other users.
To audit database users, enable separate auditing options. For example, to capture
SELECTs against the EMPLOYEES table from clients connecting directly to the database,
use this command.

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.

AUDIT SELECT TABLE ON employees BY hrappserver ON BEHALF Of phall;

2.

AUDIT SELECT TABLE ON employees BY hrappserver ON BEHALF OF ANY;

3.

AUDIT SELECT TABLE ON employees;

4.

AUDIT SELECT TABLE ON employees BY hr, oe

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.

Configuring Security and Proxy Authentication

Learning Objectives

After completing this topic, you should be able to

set up Enterprise User Security

use schemas for authentication

implement 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:

making a database schema mapping

viewing user identity information

connecting to a shared schema

creating a proxy permission

Task 1: Making a database schema mapping

You have created a schema called AKING in your database for the user AKING defined in
the directory. You now want to make a database schema mapping. Search for all users in
the cn=users, dc=easynomadtravel,dc=com search base. Configure the AKING user and
create a mapping on the User - Schema Mappings page.

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

Task 2: Viewing identity information

You have connected as the AKING user and now want to view available user identity
information. View the current user using the show user command. Then show the real
user by using the SYS_CONTEXT function. Specify the USERENV and
EXTERNAL_NAME arguments and use the DUAL table. Then use the SYS_CONTEXT
function again, providing USERENV and SESSION_USER as arguments. Include all
FROM clauses on a separate line.

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

Task 3: Connecting to a shared schema

You have created a shared schema GLOBAL_SCHEMA that is identified globally and that
has been granted the CREATE SESSION privilege. You now want to enable all enterprise
users to connect to the shared schema for your database, ORCL2. Create a database
schema mapping for the GLOBAL_SCHEMA schema. Specify that the mapping be from a
subtree of enterprise users using the string "cn=Users,dc=easynomadtravel,dc=com."

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

Task 4: Creating a proxy permission

You have created the HR_USER global user, which an application can use to connect to
the database. You now want to create a mapping that allows the enterprise user to use
this connection. Create the proxy permission and mapping. Specify a name of "hr_proxy"
for the proxy permission. Then edit the permission and enter the credentials of the system
user, with a password of "oracle," as this user has privileges to view the DBA_USERS
view. Then select HR_USER. Access the Grantees tab and add a user by searching for
LPARKS. Select this user, continue to the next screen, and confirm the configuration.

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