Oracle Database 11g Enterprise User Security and Proxy Authentication

8/10/2019 Oracle Database 11g Enterprise User Security and Proxy Authentication

1/46

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 irectory, abbreviated as OI.

Supplement

Selecting the link title opens the resource in a new browser window.

Learning Aid

!se the learning aidStyle Considerationsfor more information on the style

considerations for the Oracle ""gatabase used in this course.

#nterprise !ser $ecurity, also known as #!$, addresses the user, administrative, and

security challenges by centrali%ing storage and management of user&related information

in a 'ightweight irectory Access (rotocol, commonly known as 'A(&compliant

directory service.

)hen an employee changes *obs 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 centrali%ation can substantially lower administrative

costs while materially improving enterprise security.

#!$ requires that Oracle Identity -anagement Infrastructure must be installed. A defaultinstallation of the Oracle Application $erver Infrastructure consists of installing all

infrastructure components on the same system, including OracleA$ $ingle $ign&On, also

known as $$O Oracle Application $erver /ertificate Authority, commonly known as O/A

and Oracle elegated Administration $ervices, also referred to as A$.

This deployment is simple, and it automatically configures $$O, O/A, and A$ as part of

the repository and OI. This deployment is adequate for setting up a quick development
http://dowindow%28%27../html/laodsc_a05_it_enus_t301_frame.html')http://dowindow%28%27../html/laodsc_a05_it_enus_t301_frame.html')http://dowindow%28%27../html/laodsc_a05_it_enus_t301_frame.html')


2/46

or testing environment.

This deployment is all that is required for #!$. The Oracle 0TT( $erver, OracleA$

/ontainers for 12##, also known as O/31, and Oracle #nterprise -anager components

are always installed.

The #!$ architecture is transparent to the end user. In this e4ample, 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 epositor!, applies roles to Oracle Database.

The user is authenticated in the following process5

The user presents a username and password +or other credentials.

The directory returns the authori%ation token to the database.

The schema is mapped from the OI information.

The directory supplies the global roles for the user. #nterprise roles are defined in OI, 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 conte4t. An application conte4t supplied from OI is

called a globalconte"t.

#!$ supports three authentication methods. #ach authentication method has advantages

and disadvantages. These determine which authentication method is best for your #!$

implementation.

All three methods provide the following features5

centrali%ed 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 $$'

The three authentication methods are


3/46

passord authentication

This is a password&based authentication. (assword authentication requires separate

authentication for each database connection, retains users6 current authentication

methods, and supports Oracle 7elease 8.9 +and later clients with Oracle atabase ":g

and later.

SSL authentication! and

The $$' authentication method provides strong authentication over $$', supports single

sign&on by using $$', and supports Oracle;i+and later clients with Oracle atabase ":g

and later.

Initial configuration may be more difficult because public key infrastructure, also called (


4/46

Option 3:This option is correct. #assword$based authentication re%uires separate

authentication for each database connection. This method provides centralied

user and credential management.

Option 4:This option is incorrect. SS- authentication provides strong

authentication over SS- and also supports single sign$on using SS-.

Correct anser%s&$

". It retains users6 current authentication methods

9. It requires separate authentication for each database connection

OI has a tree structure following the 'A( standards. At each level, certain nodes are

repeated. In this e4ample, there is an orcladminuser defined at each level. There is an

orcladmin that is the administrator of the entire structure and is defined at the highest

level. #ach 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=comis the administrator that is used to manage

the us.oracle.com realm.

Graphic

The OID Structure has three levels. The dccom node is branched to cnusers,

cngroups, dcoracle, and oracle conte"t. Then the cnusers node is branched to

cnorcladmin, and dcoracle is branched to cnusers, cngroups, dcus, and

oracle conte"t. The cnusers node is branched to cnorcladmin, and the dcus

node is branched to cnusers, cngroups, and oracle conte"t. /inall!, the

cnusers node is branched to cnorcladmin.

To set up #!$, you perform the following steps5

". install Oracle Application $erver Infrastructure and

2. register the database

OI must be installed to use #!$. OI requires a metadata repository in Oracle

atabase. The simplest way to meet these requirements is to use the default installation

of Oracle Application $erver Infrastructure with a metadata repository from Oracle

!niversal Installer.

Graphic

The Oracle 0niversal Installer1 Select Installation T!pe page is open. In addition to

the Identit! Management and Metadata epositor! 23.)(456 option, which is


5/46

selected, the other two installation options available are Identit! Management

2(.78456 and Metadata epositor! 23.)(456.

The database must be configured to use 'A(. The first choice is to use omain ?ame

$ervices, commonly known as ?$, to perform automatic domain name lookup to locate

the directory on your network. The network administrator must have entered a ?$

$ervice 'ocation 7ecord, also known as $7@, into the domain name server.

The database administrator or A can use Oracle ?et /onfiguration Assistant to create

an ldap.ora file for your O7A/'#B0O-#. 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 9onfiguration Assistant, Step ' of + 1 :etwork 9onfiguration page isopen. The page provides options to register the database with the director!

service.

!se the atabase /onfiguration Assistant, also known as /A, to register the database

in the directory. 7egistration creates an entry in the directory so that the database can

bind or log in to it. The /A performs several configuration tasks, including creating a

wallet for the database and assigning a password for the wallet.

Graphic

In this e"ample, the ;es, register the database option is selected, and the

appropriate user D:, password, and wallet password are entered. The :o, donirtual #rivate Database #olicies, and Application 9onte"ts links.

'. Creating enterprise users


6/46

#nterprise users are created and managed in the directory. #nterprise 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 GLOBALL AS

!cn=scott,cn=users,dc=us,dc=oracle=dc=com!"

CREATE USER a##sc$ema IDENTIFIED GLOBALL"

e(clusive and

/reating a global user who is authenticated by a password and authori%ed by the

enterprise directory service is represented by this statement.

In this case, assume scottis a schema in the database mapped to a single enterprise

user, cn=scott, cn=users, dc=us, dc=oracle=dc=com.

The scottenterprise user must be created in the directory, and a global user scottmust

be created in every database that the enterprise user scottaccesses.

shared

)ith 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 $$',


7/46

In the e"ample, the 0- used is the following1

http1??localhost7.eas!nomadtravel.com1&&&@?oiddas?

2. 'og 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.

9. ack on the Oracle Identity -anagement $elf&$ervice /onsole page, click )irectory.

The other tabs in this page are Bome, M! #rofile, and 9onfiguration.

3. On the !sers page, click Create.

The Director! tabbed page is open. The Director! tabbed page provides the 0sers, 4roups, Services,

and Applications tabs. The 0sers tabbed page is open. The 0sers page contains user details, such as

user ID, email address, first name, and last name, in a tabular format.

=. On the /reate !ser page, enter the basic information and click Submit.

In the 5asic Information section of the 9reate 0ser page, user details such as first name, middle name,

last name, user ID, and password are entered in the corresponding fields.

In the e4ample, the user $cott Taylor is created. 0e has a user I of sta%lor. This is the

name $cott will use when he attempts to connect. 0is distinguished name or ? is

cn=ScottTa%lor, cn=users, dc=us, dc=oracle, dc=combecause of the user

creation base that was set in the directory configuration.

Graphic

The message displa!ed on successful creation of the user is the following1

Successfull! created the user sta!lor.

You can create multiple enterprise users and a mapping ob*ect in the directory. The

mapping ob*ect informs the database about how you want to map the ? of the users to

the shared schema.

#ither you can do a full ? mapping +one enterprise user to one schema or you can

do a subtree mapping C for e4ample, every user containing the ? components, dc=us,

dc=oracle, dc=comto a##sc$ema.

Graphic

The Oracle Internet Director! -ogin C =nterprise 0ser Securit! page is open. It

contains links such as Manage =nterprise Domains, Manage Databases, Manage

=nterprise 0sers, Manage 0ser Defined =nterprise 4roups, and OID ealm

Administration.

To create a shared schema mapping +subtree, perform the following steps5


8/46

". click the *anage )atabases link on the #nterprise !ser $ecurity page of atabase /ontrol

5! clicking the Manage Databases link, !ou create and manage user$schema mappings between

enterprise users stored in the director! and a specific database.

2. select the database and click Con+igureon the -anage atabases page

The selected database is orcl7.

9. click the User , Schema *appingstab on the /onfigure atabase 5 orcl2 page

5! default, the 4eneral tabbed page is open. The page also has the Administrators tab.

3. click Createon the !ser & $chema -appings tabbed page

The 0ser $ Schema Mappings tabbed page contains mapping details such as mapping t!pe.

=. select the Subtreeoption and enter the subtree ?, and

The 9reate Mapping 1 :ewMapping page is open. The entered subtree D: is

cn0sers,dceas!nomadtravel,dccom.

G. enter the global schema to which users in the subtree will mapThe database schema that is entered, in this e"ample, is 4-O5A-S9B=MA.

-ost users do not need their own schemas, and implementing shared schemas divorces

users from databases. /reate one or many enterprise users in the directory. Then those

users can access the shared schema in any database where the schema mapping e4ists.

)hen a user needs a dedicated schema, creating a schema mapping ob*ect in the !ser

?ame directory is the method for making a one&to&one mapping.

To create a subtree mapping, perform the following steps5

Graphic

The Oracle Internet Director! -ogin C =nterprise 0ser Securit! page is open.

". click the *anage Enterprise Userslink on the #nterprise !ser $ecurity page of atabase

/ontrol

5! clicking the Manage =nterprise 0sers link, !ou manage user schema mapping for individual

enterprise users. Optionall! manage enterprise roles, pro"! permissions and label securit!

authoriations.

2. select the user and click Con+igureon the -anage #nterprise !sers page

The Manage =nterprise 0sers page provides a table that lists the different users with details such as D:

and t!pe. In this e"ample, the user sta!lor is selected. The D: of the user is

cnsta!lor,cnusers,dceas!nomadtravel,dccom, and the account status of the user is =:A5-=D.

9. click the User , Schema *appingstab on the /onfigure !ser 5 staylor page

5! default, the 4eneral tabbed page is open. The other tabs in this page are 0ser $ Schema Mappings,

=nterprise oles, #ro"! #ermissions, and -abel Authoriations.


9/46

3. click Createon the !ser & $chema -appings tabbed page

The 0ser $ Schema Mappings tabbed page contains mapping details such as the mapping t!pe, schema,

and scope name.

=. select the User-ameoption, and

The D: of the user is cnsta!lor,cnusers, dceas!nomadtravel,dccom.

G. enter the global schema to which users in the subtree will map

The schema to which the enterprise user can connect is S9OTT.

It is a useful technique to move database users who currently have their own schema in

the database to enterprise users5

". migrate the database users to the directory

2. alter each schema to be identified globally, and

9. create a mapping for each user to the corresponding database schema

. *igrating and auditing users

The enterprise user who is mapped to a shared schema is unknown to the database.

)hen OI is used to authenticate the user to the database, the realname of the

enterprise user can be found in the login session by using the SS&CONTE'Tfunction.

This name is held in the e(ternal&nameattribute of the USEREN)conte4t.

The shared schema is provided as in this code.

Code

* s+l#lus sta%lor

ass-ord. //////

S0L1 SELECT user FRO2 dual"

USER

33333333333333333

GUEST

y checking the e(ternal&nameattribute of the USEREN)conte4t, the real user is

provided as in this code.

Code


10/46

S0L1 select s%s&conte(t 4!useren5! , !e(ternal&name!6 7rom

dual"

SS&CONTE'T4!USEREN)!,!E'TERNAL&NA2E!6

3333333333333333333333333333333333333333333333333333

3333

cn=Scott Ta%lor,cn=Users,dc=us,dc=oracle,dc=com

/urrent user database links require $$'&enabled network connections between the

databases. efore you can enable the current user database links, you must enable $$',

create Oracle wallets, and obtain (


11/46

The user migration utility is a command&line utility invoked with the umucommand, 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 e4ternal database users to an enterprise&user

environment in an 'A( directory. It uses the Oracle 1/ Oracle /all Interface, also

known as O/I, driver to connect to the database.

#nterprise&user administrators can select for migration any combination of the following

user subsets in a database5

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

all e4ternal 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'A( 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 process5

preparing +or the migration %phase one&

In the first part of the migration process, the ORCL&GLOBAL&USR&2IGRATION&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.

veri+ying user in+ormation %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 to&

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.

epending on whether directory entries e4ist for migrating users, the utility creates

random passwords. If migrating users are being mapped to newly created directoryentries, the utility generates random passwords, which are used as credentials for both

the database and the directory. If migrating users are being mapped to e4isting 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 DBASS8ORDand DIRASS8ORDinterface table columns. The enterprise&user


12/46

administrator can read these passwords from the interface table and inform migrating

users. The umuutility will produce a listing of the allowable parameters for each phase

with umu9EL=ES.

#uestion

)hen using the user migration utility, during which step does the utility create

random passwords based on user mappings>

Options$

". (reparing the migration

2. @erifying user information

9. /ompleting the migration

3. 'isting allowable parameters

Anser

Option 1:This option is incorrect. During the first step of using the user migration

utilit!, the ORCL&GLOBAL&USR&2IGRATION&DATAinterface table is populated

with information about the users from the database and the director!.

Option 2:This option is incorrect. The second step to using the user migration

utilit! is to verif! the user information. This is an intermediate step to allow the

enterprise$user administrator to verif! that the user information is correct in the

interface table before committing the changes to the database and the director!.

Option 3:This option is correct. During the third step, the utilit! retrieves the

information from the table and updates the director! and the database. Depending

on whether director! entries e"ist for migrating users, the utilit! creates random

passwords as needed during this phase as well.

Option 4:This option is incorrect. Ehen !ou issue the umu9EL=%escommand,

the utilit! will produce a listing of the allowable parameters for each phase.

Correct anser%s&$

9. /ompleting the migration

If auditing is turned on, Oracle atabase captures the identity of enterprise users in its

audit trails.

OI can store additional attributes for each user to help identify both authori%ed and

unauthori%ed users in both schemas5


13/46

e(clusive and

)hen enterprise users have their own schema +e4clusive 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.

)hen enterprise users access e4clusive schemas in standard auditing, the USERNA2E

column shows the user identity in the database, and the GLOBAL&UIDcolumn shows the

same user6s global identity. In fine&grained auditing, the DB&USERcolumn shows the user

identity in the database, and the GLOBAL&UIDcolumn shows the same user6s global

identity.

shared

)hen 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.

)hen enterprise users access shared schemas in standard auditing, the USERNA2E

column shows the shared schema, and the GLOBAL&UIDcolumn shows the identity of the

enterprise user. In fine&grained auditing, the DB&USERcolumn shows the shared schema,

and the GLOBAL&UIDcolumn shows the identity of the enterprise user.

Summary

In this topic, you6ve learned how to set up #nterprise !ser $ecurity.

0ntroducing Authentication

Learning Objective


recognize how authentication works in three tiered systems

1. 0denti+ying 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.


14/46

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 calledpro"! authentication.

-ote

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$part!

application. It is not an Oracle Application Server.

Although three&tier computing provides many benefits, it raises a number of new security

issues5

identi+ying the real user

)ho is the real user> atabase&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 o+ the middle tier

Hor many applications, the security model gives e4cessive privileges to the pro4y

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.

-ost organi%ations need to know the identity of the actual user who is accessing the

database. !ser 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 e4ists that the application could be bypassed.

#nd&user identification is required for these security functions5

authentication

)hen 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 e4pensive.

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

ata 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


15/46

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. -ost

organi%ations want to know on whose behalf a transaction has been accomplished, not *ustthat 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 user6s identity through the middle tier of a three&tier application, you

cannot audit actions on behalf of the user.

#uestion

Hor authentication, access control, and auditing, most organi%ations need to know

the identity of the actual user who is accessing the database.

)hich statements best describe auditing>

Options$

". )hen only the application server knows who the user is, the per&user security

enforcement must be done by the application itself

2. -ost organi%ations want to know on whose behalf a transaction has been

accomplished

9. In a three&tier system, auditing cannot be done unless you can preserve the user6s

identity through the middle tier

3. If the application is coded to use secure application roles, the application uses these

roles to control data access

Anser

Option 1:This option is incorrect. Ehen onl! the application server knows who

the user is, the application must perform per$user securit! enforcement itself. If

each application that accesses the data enforces securit!, then securit! must be

implemented in each and ever! application.

Option 2:This option is correct. Accountabilit! through auditing is a basic

principle of information securit!. Most organiations want to know on whose behalf

a transaction has been accomplished, not Fust that a particular application server

performed a transaction.


16/46

Option 3:This option is correct. Auditing in three$tier s!stems should be tied to

the issue of knowing the real userG if !ou cannot preserve the user


17/46

and disabling roles to control the access.

!nless the application keeps some kind of mapping, end&user auditing can be difficult or

impossible.

Authentication is also implemented through other methods5

the user is reauthenticated to the database

the user is identified to the database, and

the user is pro4ied

)hen 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. !sing

'A( directory services is one of the few methods that can store credentials securely.

$ingle 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 DB2S&ALICATION&INFO:SET&CLIENT&IDENTIFIER

procedure or sets CLIENT&IDENTIFIERwith the DB2S&SESSION:SET&IDENTIFIER

procedure in con*unction with the application conte4t to make this identification.

Oracle atabase supports three forms of pro4y authentication5

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. #nd 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 C in this case, a global user C is authenticated by the middle&tier server and

passes either a distinguished name, also known as ?, or certificate through the middle

tier for retrieving the end user name.


18/46

#uestion

)hich forms of pro4y authentication are supported by Oracle atabase>

Options$

". 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

9. The end user is authenticated by the middle&tier server and passes a certificate

through the middle tier

3. The user presents a credential to the application and the application authenticates

the user to the database

=. The application can identify the user with a token of some kind

Anser

Option 1:This option is correct. In one form of pro"! authentication, the middle$

tier server authenticates itself to the database server and provides an end user

name. The end user has alread! authenticated to the middle$tier server. =nd user

identities can be maintained all the wa! through to the database.

Option 2:This option is correct. In another form of pro"! authentication, the

database user is not authenticated b! the middle$tier server. The end user identit!

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 pro"! authentication, the end

user in this case, a global user is authenticated b! 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

necessaril! 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 thedatabase, the application can identif! the user with a token of some kind. This

token maps the end user to a session.

Correct anser%s&$

". The middle&tier server authenticates itself to the database server and provides

an end user name


19/46

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

9. The end user is authenticated by the middle&tier server and passes a certificate

through the middle tier

. eauthenticating the user

To meet the requirements of database&level security, every user C the application server,

end users, and pro4y users C must be identified to the database. 7eauthentication occurs

when a user is identified to the middle tier and then is identified again to the database.

In clientDserver systems, authentication tends to be straightforward C the client

authenticates to the server.

In three&tier systems, authentication is more difficult because there are several potential

types of authentication5

middle tier to database

ecause 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 atabase 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 $$'.

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.

$uch authentication can be mutual by using $$' C that is, the middle tier authenticates to

the client *ust 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. #nd&

user reauthentication from the middle tier to the database is problematic in three&tier

systems.

The following problems can occur in three&tier systems5

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.


20/46

improper use o+ passords

Hor 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.

oth approaches involve security risks because the middle tier is trusted to handle the

user6s password properly, and not to allow it to be used improperly.

netor/ overhead

Two sets of authentication handshakes per user involve considerable network overhead.

absence o+ 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 o+ end,user reauthentication! and

Hor some authentication protocols, end&user reauthentication is *ust not possible.

Hor e4ample, many browsers and application servers support the $$' protocol. 0owever,

$$' 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 o+ username

The middle tier may map the username provided during the middle&tier authentication to a

database username. )here this mapping is held is the problem. oes the mapping include

passwords> Is the mapping secure>

One solution is for the middle tier to use username mapping through an 'A(&compliant

directory service, such as Oracle Internet irectory, commonly referred to as OI.

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 privileges5


21/46

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 T(, 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 *obs. 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

e4posed.

limited privileges

-ore 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.

Hor e4ample, many organi%ations would prefer that users have different privileges,

depending on where they are connecting from. !sers 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 e4ercise all

privileges that they are otherwise entitled to have.

Summary

In this topic, you6ve learned how authentication works in three&tiered systems.

2ro(y Authentication Solutions

Learning Objective


recognize proxy authentication solutions

1. Using pro(y authentication solutions

(ro4y 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. oth these users are

identified to the database. The second is for the end user who is known only to the

application.


22/46

Implementing pro4y authentication provides the following features5

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

-any organi%ations want to know who the user is through all the tiers of an application,

without sacrificing the benefits of a middle tier. Oracle atabase supports pro4y

authentication for preserving the user identity through the middle tier of an application.

The real user can be identified in the following situations5

database users have a database account that maintains their identity

enterprise&user identities are maintained in Oracle Internet irectory, commonly referred to as

OI, and are identified by using a distinguished name or ?, and

application users are known to the application, but not to the database

atabase and enterprise users can be reauthenticated to the database after connecting

to the application server.

atabase users can supply a password that is passed to the database. #nterprise users

can be authenticated to the database by a password, certificate, or


23/46

'. Authenticating users

Hor enterprise users or database users, Oracle /all Interface, also known as O/I, or 1ava

atabase /onnectivity, commonly referred to as 1/, 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 stages5

". the client authenticates itself to the middle tier

2. the middle tier authenticates itself to the database

9. the middle tier creates sessions for users, and

3. the database verifies the middle tier

The client authenticates to the middle tier, using whatever form of authentication the

middle tier accepts. Hor e4ample, the client can authenticate to the middle tier by using a

username and password, or an .=:J certificate by means of secure sockets layer,

commonly referred to as $$'.

The middle tier creating the lightweight client sessions must first connect to the databaseas 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 $ecurity, such as a


24/46

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 $$', the middle tier can provide the

distinguished name or ? from the user6s .=:J certificate or the certificate itself in the

session.

The database uses the ? to look up the user in Oracle Internet irectory, commonly

referred to as OI. The user6s roles are automatically retrieved from OI after the session

is established.

passord,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 OI. If the session also provides a

password for the user, the database verifies the password against that stored in OI. Theuser6s roles are automatically retrieved from OI 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 OCISessionBe;incall fails if the application server is not allowed to pro4y 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 anattribute 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.

. )atabase and enterprise users

-iddle&tier authentication allows one 1ava atabase /onnectivity, commonly referred to

as 1/, connection +session to act as a pro4y for other 1/ connections. !se the

CONNECTT9ROUG9clause in the ALTERUSERcommand to indicate that the user is

authenticated through a middle tier.

atabase users can be authenticated using two methods5

Code


25/46

ALTER USER #$all

GRANT CONNECT

T9ROUG9 AS)R"

ALTER USER #$all

GRANT CONNECT

T9ROUG9 AS)R

AUT9ENTICATION RE0UIRED ASS8ORD"

ithout a database passord and

)hen the middle tier authenticates the user, you may not want to give the middle tier the

user6s 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 9ALLby using the already authenticated credentials of the

middle&tier AS)R. This method assumes that the middle tier is trusted to perform the

authentication.

The created session behaves as if 9ALLhas been connected normally 9ALLdoes not

have to divulge the password to the middle tier. The pro4y session accesses the schema

of 9ALL. This method is sometimes appropriate for application servers in a trusted

region.

ith a database passord

To authenticate the user with a password, use this command. The Oracle instance e4pects

the pro4y to authenticate the user, unless you specify the AUT9ENTICATIONRE0UIRED

clause. The AUT9ENTICATIONRE0UIREDclause is relevant only as part of a GRANT

CONNECTT9ROUG9RO'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.

Hor enterprise users, you can authenticate with a distinguished name and a certificate. In

both the DISTINGUIS9EDNA2Eand CERTIFICATEcases, the pro4y 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 pro4ied for.


26/46

Hor e4ample, CN=#$all,OU=americas,O=oracle,L=red-oods$ores,ST=ca,

C=uscan 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 'ightweight irectoryAccess (rotocol, also known as 'A(, directory.

Code

ALTER USER #$all

GRANT CONNECT

T9ROUG9 AS)R

AUT9ENTICATED USING DISTINGUIS9ED NA2E"

To pass the distinguished name of the client to the database, the application server would

call OCIAttrSet46with this pseudo interface.

Code

OCIAttrSet 4

OCISession /session&$andle,

OCI&9TE&SESSION,

l(st# /distin;uis$ed&name,

4u,

OCI&ATTR&DISTINGUIS9ED&NA2E,

OCIError /error&$andle 6"

To authenticate the user with a certificate, use this command.

In both the DISTINGUIS9EDNA2Eand CERTIFICATEcases, the pro4y has already

authenticated and is acting on behalf of a global database user.

Code

ALTER USER #$all

GRANT CONNECT

T9ROUG9 AS)R

AUT9ENTICATED 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 .=:J.

Code


27/46


28/46

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

that the middle tier is trusted to perform authentication>

Options$

". )ith a database password

2. )ith a certificate

9. )ith a distinguished name

3. )ithout a database password

Anser

Option 1:This option is incorrect. Ehen authenticating the user with a database

password, the middle tier is not assumed to be trusted. Eith this method, the

middle tier cannot perform an! authentication.

Option 2:This option is incorrect. Ehen using a certificate, the pro"! has alread!

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 pro"ied for. This name is provided b! the

application server when the application server connects for the user.

Option 4:This option is correct. Ehen the middle tier authenticates the user, !ou

ma! not want to give the middle tier the user


29/46

The AUT9ENTICATEDUSINGCERTIFICATEclause is discouraged, and ma! not

be supported in future versions.

This command contains two additional keywords.

Code

ALTER USER #$all

GRANT CONNECT

T9ROUG9 AS)R

AUT9ENTICATED USING CERTIFICATE

TE!':@>! )ERSION!!"

TYPE

The TEke!word is the t!pe of certificate to be presented. If !ou do not specif! the t!pe,

the default is ':@>.VERSION

The )ERSIONke!word is the version of the certificate to be presented. If !ou do not

specif! the version, the default is .

Summary

In this topic, you6ve learned how pro4y authentication is implemented.

Enterprise User 2ro(y

Learning Objectives


manage users authenticated by proxy authentication

recognize how to audit users with proxy authentication

1. Using an enterprise user pro(y

(ro4y access through $K'L(lus is possible when

Code

CONNECT AS)R9ALLa##s5r-d


30/46

CONNECT raee5AS)Rraee5-d

both users are /non to the database and

)hen both users are known to the database, the AS)Ruser can connect on behalf of

9ALL. )hen connected, the user is 9ALLand the schema is 9ALL.

The application can connect as 9RAand then initiate a session for 9ALL. The AS)R

user may have authority to enable some or all of the roles granted to 9ALL.

the user is un/non to the database %enterprise user pro(y&

)hen 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, AS)R, is the

user connected to the database.

The target user is not IDENTIFIEDGLOBALL, but allows CONNECTT9ROUG9

ENTERRISEUSERS. )hen connected, the user is AS)R. The users provide their own

enterprise user credentials, but connect as the target user with the privileges and roles of

the target user C in this case, AS)R.

In both cases, notice that the session is for the user named in the .

Graphic

The users within the H are #BA-- and A##S>.

Code

CONNECT AS)R9ALLa##s5r-d

CONNECT raee5AS)Rraee5-d

In Oracle atabase, the enterprise user pro4y is available to allow you to use #nterprise

!ser $ecurity, also known as #!$, in combination with e4isting applications that use the

one big&application user model.

All the users have been connecting as AS)R, and now they have been given

enterpriser user credentials in the directory. They can continue to use the application with

a pro4y connect, as in this e4ample. The users provide their #!$ credentials and the

target user, and connect to the database as the target user.

Code


31/46

CONNECT ;eor;eAS)R;eor;e-d

#nterprise users can be individually granted permissions to pro4y as local database

users. #nterprise user pro4y permissions are created and stored in Oracle Internet

irectory.

A permission allows one or more enterprise users or groups to pro4y as a target database

user. y default, domain administrators manage pro4y permissions in the directory for an

enterprise domain. These permissions are configured and managed using #nterprise

-anager #nterprise !ser $ecurity pages.

In most cases, enterprise users, such as ;eor;e, are unknown to the database. They

are calledpro"!users. The mapping of a pro4y user to a database user is called apro"!

permission. The user making the connection, AS)R, is called the target user, is a

database user, and is not identified globally.

/onsider the case where the ARTSapplication connects to the database as theARTS&GUESTuser and creates a connection pool. The ARTS&GUESTuser has

privileges to access the ARTS&Aschema. These privileges may be granted through

roles granted to ARTS&GUEST. ARTS&GUESTis not a global user.

I2and RAEE)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 ARTS&GUESTpro4y schema is granted the roles

granted to the ARTS&GUESTuser. #very user connecting to the ARTS&GUESTschema

receives all the roles and privileges granted to ARTS&GUESTby default. The application

may enable secure application roles to allow RAEE)and I2the individual access

required.

Graphic

aFeev and Jim are connected to the shared schema, #ATSD5.

aFeev is connected through the following command1

9O::=9T AJ==>H#ATS40=ST?pwd

And Jim is connected through the following command1

9O::=9T JIMH#ATS40=ST?pwd

The A still controls which database users can be pro4ied. The A changes the pro4y

grant with this command.


32/46

Only local database schemas can be granted CONNECTT9OUG9ENTERRISEUSERS.

Only users designated as such can be added as a database target user to a pro4y

permission in the directory.

Code

ALTER USER #arts&;uest GRANT CONNECT T9OUG9 ENTERRISE

USERS"

You can create an enterprise user pro4y by performing the following steps5

". create a named pro4y permission, RO'?in the directory

2. assign enterprise users I2and RAEE)to the pro4y permission

9. assign a database target user, ARTS&GUEST, to the pro4y permission, and

3. change ARTS&GUESTin the database with this command

The command used to change the database is the following1

A-T= 0S= #ATS40=ST 9O::=9T TBO04B =:T=#IS= 0S=S

)hen I2or RAEE)want to create a session, the application issues an O/I call

equivalent to this $K' command.

The ARTS&DBdatabase contacts the directory to authenticate the enterprise users. The

roles are assigned based on the roles assigned to the target database user,

ARTS&GUEST.

Code

CONNECT I2ARTS&GUEST#-dH#arts&d::> 3 roduction

?M DATABASE oracle Oracle Ad5anced Securit%. encr%#tion

ser5ice 7or Linu(. )ersion

??:?:>::> 3


39/46

roduction

?M DATABASE oracle Oracle Ad5anced Securit%.

cr%#to3c$ecsummin; ser5ice 7or

Linu(.

)ersion ??:?:>::> 3 roduction

The )*SESSION&CONNECT&INFOview contains four columns.

Code

S0L1 select SID, AUT9ENTICATION&TE,

J OSUSER, NET8OR&SER)ICE&BANNER

7rom 5*session&connect&in7o -$ere SID = ?M"

SI

DAUT9ENTICAOSUSERNET8OR&SER)ICE&BANNER

33333 3333333333 333333

333333333333333333333333333333333333333

?M DATABASE oracle TCI NT rotocol Ada#ter 7or

Linu(.


?M DATABASE oracle Oracle Ad5anced Securit%. encr%#tion

ser5ice 7or Linu(. )ersion

??:?:>::> 3

roduction

?M DATABASE oracle Oracle Ad5anced Securit%.

cr%#to3c$ecsummin; ser5ice 7or

Linu(.


SID

The SIDcolumn contains the session identifier.

AUTHENTICA


40/46

The AUT9ENTICATION&TEcolumn stores values on how the user is authenticated. The

values are DATABASE username and password, OS e"ternal operating s!stem,

NET8OR network or Oracle Advanced Securit!, also known as ASO, and RO' O9I

pro"! connection.

OSUSER

The OSUSERcolumn contains the e"ternal username for the database user.

NETWORK_SERVICE_BANNER

The NET8OR&SER)ICE&BANNERcolumn contains product banners for each Oracle :et

Service used for this connection, with one row per banner.

#uestion

)hich )*SESSION&CONNECT&INFOcolumn would you query to determine the

e4ternal O$ and O/I pro4y connection>

Options$

". SID

2. AUT9ENTICATION&TE

9. OSUSER

3. NET8OR&SER)ICE&BANNER

Anser

Option 1:This option is incorrect. The SIDcolumn contains the session identifier.

Option 2:This option is correct. The AUT9ENTICATION&TEcolumn stores

values on how the user is authenticated. The values are in DATABASE, OS,

NET8OR, and RO'.

Option 3:This option is incorrect. The OSUSERcolumn contains the e"ternal

username for the database user.

Option 4:This option is incorrect. The NET8OR&SER)ICE&BANNERcolumn

contains product banners for each Oracle :et Service used for the connection,

with one row per banner.

Correct anser%s&$

2. AUT9ENTICATION&TE

. Auditing user actions


41/46

You can use the pro4y authentication features of the database to audit the actions that

the middle tier performs on behalf of a user in two situations5

Code

AUDIT SELECT TABLE ON em#lo%ees

B $ra##ser5er ON BE9ALF OF #$all"

AUDIT SELECT TABLE

ON em#lo%ees

B $ra##ser5er

ON BE9ALF OF AN"

auditing on behal+ o+ a speci+ic user and

Hor e4ample, suppose an application server 9RASER)ERcreates multiple lightweight

sessions for the 9ALLuser. You can enable auditing for SELECTs on the E2LOEES

table that 9RASER)ERinitiates for 9ALL.

auditing on behal+ o+ any user

Alternatively, you can enable auditing on behalf of multiple users connecting through a

middle tier.

The ONBE9ALFOFauditing option audits only the SELECTstatements being initiated by

9RASER)ERon behalf of other users.

To audit database users, enable separate auditing options. Hor e4ample, to capture

SELECTs against the E2LOEEStable from clients connecting directly to the database,

use this command.

Code

AUDIT SELECT TABLE

ON em#lo%ees"

Hor audit actions taken on behalf of the real user, you cannot audit CONNECTONBE9ALF

OFDNbecause the distinguished name is not known to the database. 0owever, if the

user accesses a shared schema +for e4ample, AUSER, you can audit CONNECTON

BE9ALFOFAUSER.

)ith enterpriser user pro4y, the distinguished name of the enterprise user is available in

the RO'&ENTERRISE&IDENTITattribute of the USEREN)conte4t. )ith a fine&

grained auditing C also known as HNA C event handler, the

RO'&ENTERRISE&IDENTITattribute can be captured from the USEREN)conte4t.


42/46

#uestion

)hich statement represents an e4ample of auditing on behalf of any user>

Options$

". AUDITSELECTTABLEONem#lo%eesB$ra##ser5erONBE9ALFO7#$all"

2. AUDITSELECTTABLEONem#lo%eesB$ra##ser5erONBE9ALFOFAN"

9. AUDITSELECTTABLEONem#lo%ees"

3. AUDITSELECTTABLEONem#lo%eesB$r,oe

Anser

Option 1:This option is incorrect. This statement is used to enable auditing for

SELECTs on the E2LOEEStable that 9RASER)ERinitiates for the user

9ALL.

Option 2:This option is correct. ;ou 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 E2LOEES

table from clients connecting directl! to the database, !ou can use this statement.

Option 4:This option is incorrect. To capture SELECTs against the E2LOEES

table from the 9Rand OEusers, !ou can use this statement.

Correct anser%s&$

2. AUDITSELECTTABLEONem#lo%eesB$ra##ser5erONBE9ALFOFAN"

The DBA&ST2T&AUDIT&OTSview describes the current system auditing options across

the system and by the user.

The following columns are related to auditing the actions of the pro4y user5

USER_NAMEand

If auditing user actions, the username is recorded. If access by a pro4y on behalf of a

client is being audited, ANCLIENTis recorded. Otherwise, NULLis recorded for system&

wide auditing.

PROXY_NAME

The name of the pro4y user who is performing an operation for the client is recorded. If the

client is performing the operation directly, NULLis recorded.


43/46


44/46

to connect to the shared schema for your database. You also want to create and

configure an enterprise pro4y user.

In this e4ercise, you6re required to associate an enterprise user with a database schema,

test the connection, enable the use of a shared schema, and create a pro4y permission.

This involves the following tasks5

making a database schema mapping

viewing user identity information

connecting to a shared schema

creating a pro4y permission

3as/ 1$ *a/ing a database schema mapping

You have created a schema called A


45/46


46/46

Steps list

0nstructions

". /lick Create

2. Type $rro(%in the ?ame te4t bo4 and click Continue

9. #nsure hr6pro(yis selected and click Edit

3. /lick Add

=. Type s%stemin the !ser ?ame te4t bo4, type oraclein the (assword te4t bo4, and click Go

G. $elect the 76USEcheckbo4 and click Select

8. /lick the Granteestab

;. /lick Add

J. Type LARSin the ?ame te4t bo4 and click Go

":. $elect the cn8L2A"S!cn8users! dc8easynomadtravel!dc8comcheckbo4 and click Select

"". /lick Continue

"2. /lick O"

Documents

Oracle Database 11g Enterprise User Security and Proxy Authentication