Skip Headers

< /tr>
Oracle® Database Advanced Security Administrator 's Guide
10g Release 1 (10.1)
Part Number B10772-01
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 < img src="../../dcommon/gifs/indxicon.gif" alt="Go to Index" border="0">
Index		 Go to Master Index
Master Index		 Go to Feedback page
Feedback
Go to previous page
Previous		 Go to next page Next
View PDF

11
Getting Started with Enterprise User Security

Enterprise User Security, a cr itical component of Oracle Identity Management, lets you create and administer large numbers of users in a secure, LDAP-compliant directory service. The following topics in this chapter explain what Enter prise User Security is and how it works:

Introduction to Enterprise User Se curity

This section provides an overview of Enterprise User Security , explaining the benefits, how enterprise users access resources across a distributed database system, and how they are authenticated . It contains the following topics:

The Challenges of User Management

Administrators must keep user information up to date and secure for the entire enterprise. This task becomes more difficul t as the number of applications and users increases. Typically, each user has multiple accounts on different databases, which means e ach user must remember multiple passwords. The results of these conditions are too many passwords for users to remember and too many accounts for administrators to effectively manage.

With thousands of users accessing databa se accounts, administrators must devote substantial resources to user administration. Common information used by multiple application s, such as usernames, telephone numbers, and system roles and privileges, is typically fragmented across the enterprise, contributing to data that is redundant, inconsistent, and difficult to manage.

In addition to user and account management problems, these conditions produce security problems as well. For example, any time a user leaves a company or cha nges jobs, that user's privileges should be changed the same day in order to guard against their misuse. However, in a large enterpri se, if you have too many user accounts distributed over multiple databases, an administrator may be unable to make such timely change s. If your users have too many passwords, then they may write them down (making them easy for others to copy), choose passwords that are easy to remember (making them easy for others to guess), or choose the same password for multiple applications (making a compromi sed password a greater security risk). All of these user efforts to keep track of their multiple passwords can compromise the securit y of the enterprise.

Enterprise User Security: The Big Picture

Enterprise Use r Security addresses user, administrative, and security challenges by relying on the identity management services supplied by Oracle Internet Directory, an LDAP-compliant directory service. Identity management is the process by which the complete security life cycle for network entities is managed in an organization. It typically refers to the management of an organization's application users, wh ere steps in the security life cycle include account creation, suspension, privilege modification, and account deletion.

Figure 11-1 shows how Enterprise User Security fits into the Or acle security architecture, which uses the Oracle Identity Management infrastructure as its foundation.

< h4 class="FTW">Figure 11-1 Enterprise User Security and the Oracle Security Architectur e Text description of asoag038.gif follows

Text description of the illustration asoag038.gif

Users benefit from En terprise User Security through single sign-on (SSO) or single password authentication, depending on the configuration chosen by the administra tor. Using single sign-on, users need to authenticate only once and subsequent authentications take place transparently. This functio nality requires SSL, and should not be confused with OracleAS Single Sign-On, a component of Oracle Identity Management infrastructur e.

Single password authentication lets users authenticate to multiple databases with a sing le global password although each connection requires a unique authentication. The password is securely stored in the centrally locate d, LDAP-compliant directory, and protected with security mechanisms including encryption and Access Control Lists (ACLs). This approach improves usability by reducing the number of passwords to remember a nd manage, and by eliminating the overhead of setting up SSL.

Enterprise User Security requ ires Oracle Internet Directory 10g (9.0.4). Other LDAP-compliant directory services are supported by using Or acle Internet Directory Integration Platform to synchronize them with Oracle Internet Directory.

This section contains the following topics:

How Oracle Intern et Directory Implements Identity Management

Oracle Internet Director y uses the concept of identity management realms to organize information in the directory information tree (DIT), which is a hierarch ical tree-like structure consisting of directory object entries. In a directory, each collection of information about an object is ca lled an entry. This object may be a person, but it can also be information about a networked device, such as configuration informatio n. To name and identify the location of directory objects in the DIT, each entry is assigned a unique distinguished name (DN). The DN of an entry consists of the entry itself and its parent entries, connected in ascending order, from the entry itself up to the root (top) entry in the DIT.

About Identity Management Realms

An identity manageme nt realm is a subtree of directory entries, all of which are governed by the same administrative policies. For example, all employees in an enterprise who have access to the intranet may belong to one realm, while all external users who access the public application s of the enterprise may belong to another realm. Use of different realms enables an enterprise to isolate user populations and enforc e different administrative policies, such as password policies or naming policies, in each realm.

About Identity Management Realm-Specific Ora cle Contexts

Each identity management realm has a realm-specific Ora cle Context (realm Oracle Context) that stores Oracle product information for that realm. A realm Oracle Context stores application d ata, how users are named and located, how users must be authenticated, group locations, and privilege assignments--all specific to th e particular identity management realm in which the realm Oracle Context is located.

See Also:

Enterprise Users Compared to Database Users

Database users a re typically defined in the database by using the CREATE USER statement as follows:

CREATE USER username IDENTIFIED BY password;

This creates a database user, associated with a user schema, who can access the database and be authenticated by using a password with the CONNECT command as follows:

connect username/password@database_service_name

Database users must be created in each database they need to access, and they can choose a different password for each database. Database user privileges are contr olled by local roles in each database.

In contrast, enterprise users are provisioned and ma naged centrally in an LDAP-compliant directory, such as Oracle Internet Directory, for database access. Enterprise users have a uniqu e identity in the directory called the distinguished name (DN). When en terprise users log on to a database, the database authenticates those users by using their DN.

Enterprise users are defined in the database as global users. Global users can have their own schemas, or they can share a global schema in the databases they access. You can create enterprise users by using the GLOBALLY clause in the CREATE U SER statement in two different ways.

You can specify a user's directory DN with an < code>AS clause, which is shown in the following statement:

CREATE USER username<
/em> IDENTIFIED GLOBALLY AS '<DN of directory user entry>';

In this case, they have a schema allocated exclusively to them.

Alternatively, you can spe cify a null string with the AS clause as the following statement shows:

CREATE
 USER username IDENTIFIED GLOBALLY AS '';

When you specify a null string with the AS clause, the directory maps authenticated users to the appropriate database schema. In this case, mul tiple users can be mapped to a shared schema based on the mapping information set up and stored in Oracle Internet Directory.

When enterprise users connect over SSL to the database, they do not use a password. Instead they u se the following CONNECT command, which looks up the wallet location based on information in the client's sqlnet.o ra file:

connect/@database_service_name

Password-authenticated enterprise users use the same CONNECT statement to connect to th e database as regular database users. For example, password-authenticated enterprise users connect to the database by using the follo wing syntax:

connect username/password@database_service_name

When the database recei ves a connection request from an enterprise user, the database refers to the directory for user authentication and authorization (rol e) information.

See Also:

About Enterprise User Schemas

Enterprise us ers can retain their individual database schemas (exclusive schemas) or share schemas if the enterprise security administrator maps t hem to a shared schema.

Exclusive-Schema Enterprise Users

If users want to re tain their individual schemas in the databases that they access, then

  • Create enterprise users in the directory, and
  • Create a global user sch ema for each user in each database that they access.

Creating separate accounts for e ach enterprise user on each database that they access results in significant overhead. Instead, creating enterprise users who access a single, generic shared schema in each database increases the efficiency of the enterprise user solution.

Shared Schema Enterprise Users

To receive the real benefit of the enterprise user solution, you can use shared schemas for your enterprise users. For this strategy

  • C reate enterprise users in the directory,
  • Create a single shared schema in each database, and
  • Create a single shared schema mapping in Oracle Internet Direct ory.

Mapping enterprise users to a generic, shared schema on each of the databases th at they access greatly reduces the overhead of creating separate schemas for each enterprise user.

Shared schema enterprise users can be mapped to generic, shared schemas on all of the databases that they access, or they can have exclusive schemas on some databases and shared schemas on others. The shared schema mappings are stored in the directory.

< a name="1016848">
See Also:

"About Using Shared Schemas for Enterprise User Security" for more information about creating and using shared schemas for enterprise users.

How Enterprise Us ers Access Database Resources with Database Links

Database links are network objects stored in the local database or in the network definition that identify a remote database, a communication path to t hat database, and optionally, a username and password. Once defined, the database link is used to access the remote database. Oracle Database supports connected user links, fixed user links, and current user links.

Enterpris e users can use all three types of database links. Connected user links are accessed by a local user who has an account on the remote server. Fixed user links contain a username and password as part of the link definition. Current user database links allow enterpris e users to access objects on remote databases without passing authentication information during link execution, or storing authentica tion information in the link definition. They require SSL for the database network connections, which means public key infrastructure (PKI) credentials must be obtained and maintained for the databases. Current user database links can be used to connect to the remot e database only as an enterprise user.

H ow Enterprise Users Are Authenticated

Enterprise User Security suppo rts the following authentication methods:

  • Password-based authe ntication
  • SSL-based authentication
  • Kerberos-based authentication

Each authentication method has advantages a nd disadvantages. Table 11-1 summarizes the criteria for selecting which authentication metho d is best for your Enterprise User Security implementation.

Table 11-1 Enterprise User Security Authentication: Selection C riteria
See Also:
Password Authentication SSL Authentic ation Kerberos Authentication

Password-based authentication.

Provides strong authentication over SSL.

Provides strong authentication by using Kerberos, version 5 tickets.

Provides centralized user and password management.

Provides centralized user and PKI credential/wallet management.

Provides centralized user and Kerberos credential management.

Separate authentications required for each database connection.

Supports single sign-on (SSO) using SSL.

Supports single sign-on (SSO) using Kerberos, version 5 encrypted tickets and authenticato rs, and authentication forwarding.

< /a>

Retains users' current authentication methods.

I nitial configuration maybe more difficult because PKI credentials must be generated for all users. (Dependent on administrators' PKI knowledge)

Initial configuration maybe more difficult because Kerbe ros must be installed and configured to authenticate database users.

User identity can be used in two-tier or multitier applications. OracleAS Single Sign-On users and enterprise users use the same stored password.

C ompatible with either a two-tier or multitier environment.

Compatib le with either a two-tier or multitier environment.

Supports Oracle Release 7.3 and later clients with an Oracle Database 10g .

Supports Oracle8i and later clients with an Oracle Database 10g.

Supports Oracle Dat abase 10g clients and later with an Oracle Database 10g.

Supports current user database links only if the connection between databases is over SSL.

Supports current use r database links.

Supports current user database links only if the connection between databases is over SSL.

Can use third-party directories to store users if synchronized with Oracle Internet Directory.Foot 1

Can use third-pa rty directories to store users if synchronized with Oracle Internet Directory.Foot 2

Can use third-party directories to store users if synchron ized with Oracle Internet Directory.Foot 3

1 If third-party directory is Microsoft Active D irectory, then when user passwords change, they must be changed in both Active Directory and in Oracle Internet Directory.
2 Must modify the Directory Integration Services agent to synchronize user PKCS #12 attributes.
3 If third-party directory is Microsoft Active Directory, th en login to Windows gives you single sign-on login to databases. However, you must modify the Directory Integration Services agent fo r other third-party directories to synchronize the KrbPrincipalName attribute. This synchronization is automatic for Mic rosoft Active Directory.
Note:

Enterprise User Security supports three-tier environments. Oracle Database 10g proxy authentication features ena ble (i) proxy of user names and passwords through multiple tiers, and (ii) proxy of X.509 certificates and distinguished names throug h multiple tiers.

See Also:

About Enterprise User Security Directory Entries

In a directory, each collection of information about an object is ca lled an entry. For Enterprise User Security, elements such as users, roles, and databases are directory objects and information about these objects are stored as entries in the directory.

Each entry in the directory is uniqu ely identified by a distinguished name (DN). The DN tells you exactly where the entry resides in the directory entry hierarchy, which is commonly called the directory information tree (DIT).

Note:

In the Oracle Database 10g release, databases must be registered in a comp lete identity management realm of Oracle Internet Directory.

See Also:

Oracle Internet Directory Administrator's Guide for a complete discussion of directory entries.

The following sections describe directory entries related to Enterprise User Security:

Enterprise Users< /font>

An enterprise user is one that is defined and managed in a directory. Each enterprise user has a unique ident ity across an enterprise. Enterprise user entries can reside at any location within the identity management realm, except within the realm Oracle Context.

The entries described in the following sections can only reside withi n a realm Oracle Context.

Enterprise Roles

Enterprise users can be assigned an enterprise role, which determines their access privileges on databases. These enterprise roles are stored and managed in a directory. Figure 11-3 shows an example of an enterprise role called Manager und er the OracleDefaultDomain.

An enterprise role can consist of one or many global roles, each one of which is defined in a specific d atabase. A global role includes privileges contained in a database, but the global role is managed in a directory. An enterprise role is thus a container of global roles. For example, the enterprise role sales_manager could contain the global role manage_leads with its privileges on the Customer Relationship Management (CRM) database, and the bonus_approval global role with its privileges on the Finance database. Figure 11-2 illustrates this example .

Figure 11-2 Example of Enterprise Roles

Text description of asoag033.gif follows

Text description of the illustration asoag033.gif

An enterprise role can be assigned to one or more enterprise users. For example, you could assi gn the enterprise role sales_manager to a number of enterprise users who hold the same job. This information is protecte d in the directory, and only a directory administrator can manage users and assign their roles. A user can be granted local roles and privileges in a database in addition to enterprise roles.

Enterprise role entries are stor ed in enterprise domain subtrees. Each enterprise role contains informa tion about associated global roles on each database server and the associated enterprise users. The Enterprise Domain Administrator creates and manages enterprise roles by using Enterprise Security Manage r.

See Also:

"Administering Enterprise Roles" for information about using Enterprise Security Manager to create and manage enterprise roles.

Ent erprise Domains

An enterprise domain is a group of databases and enterprise roles. An example of a domain cou ld be the engineering division in an enterprise or a small enterprise itself. Figure 11-3 sho ws an example of an enterprise domain called Services that resides under the OracleDBSecurity entry in an identity management realm. It is here, at the enterprise domain level, that the Enterprise Domain Administrator , using Enterprise Security Manager, assigns enterprise roles to users and manages enterprise security. An enterprise do main subtree in a directory is composed of three types of entries: enterprise role entries, user-schema mappings, and the enterprise domain administrator's group for that domain. Enterprise domains are used to manage information that applies to multiple databases. A ll user-schema mappings entries contained in an enterprise domain apply to all databases in the domain. If you need to apply differen t user-schema mappings to individual databases, then use Database Server entries, which are discussed in the following section.

< a name="1022332">

Enterprise roles apply to specific databases in the domain, as explained in the previous section . Enterprise roles, domain-level mappings, and the domain administrators group are all administered by using Enterprise Security Mana ger.

Note:

The database obtains a user's global roles from the directory as part of the login process. If you change a user's global roles in the directory, then those changes do not take effect until the next time the user logs in to the database.

See Also:

"Administering Enterprise Domains"

Database Server Entries

A database server entry (represented as "Sales" in Figure 11-3) contains information about one database server. It is created by the Database Configuration Assistant during database registration. A database server entry is the parent of database-leve l mapping entries that contain mapping information between full or partial user DNs and Oracle shared schema names (user-schema mappi ngs). Database-level mapping entries are created by the Database Administrator by using Enterprise Security Manager. This tool is also used to manage the database administrator's group, which contains adm inistrators for a specific database. The directory entry for this group is located under the database server entry in the DIT.

Figure 11-3 Related Entries in a Realm Oracle Context

Text description of asoag032.gif follows

Text description of the illustration asoag032.gif

User-Schema Mappings

A user-schema mapping entry contains mapping information between a DN and an Oracle database schema. The users referenced in the mapping are connected to the specified s chema when they connect to the database. User-schema mapping entries can apply only to one database or they can apply to all database s in a domain, depending on where they reside in the realm Oracle Context.

Administrative Groups

An identity management realm contains administrative groups that are related to Enterprise User Security. Figure 11-3 shows these administrative groups in a realm in the triangle labeled "Groups." Each a dministrative group includes an Access Control Lists (ACLs) that contro ls access to the group itself. ACLs elsewhere in the directory may refer to these groups, which allows directory administrators acces s to perform necessary administrative tasks. The administrative user who creates the realm automatically becomes the first member of each of these groups, thus gaining the associated privileges provided by each group, but can be removed.

The relevant administrative groups in a realm are described in Table 11-2.

Note:

Observe the following practices. Using other methods may break the security configur ation for Enterprise User Security objects and may break enterprise user functionality as well.

  • Do not modify the ACLs for the objects contained in a realm Oracle Context. Modified realm Oracle Con text object ACLs are not supported.
  • Use only Oracle tools, such as Enterprise S ecurity Manager Console, Enterprise Security Manager, and Database Configuration Assistant, to modify Enterprise User Security direct ory entries.
Table 11-2  Administrative Groups in a Realm Or acle Context
Administrative Group Description

OracleDBCreators

(Called "Database Registration Admins" in Release 9.2 and earlier versions of Enterprise Se curity Manager)

DN: (cn=OracleD BCreators,cn=OracleContext...)

Default owner: OracleContextAdmins

During default realm Oracle Context creation, Oracle Internet Direct ory Configuration Assistant sets up the following access rights/permissions for these group members:

  • Add permission for database service objects in the realm Oracle Context
    • Modify permission for the Default Domain

OracleDBCreators create new databases and register them in the directory by using Database Configuration Assistant< /p>

OracleContextAdm ins

(Called "Full Context Management" group in Release 9.2 and earlier versions of Enterpris e Security Manager)

DN: (cn=Ora cleContextAdmins,cn=Groups,cn=OracleContext...)

Default owner: The user who created the identity management realm. (If it is the realm created during installation, then it is orcladm in.)

OracleContextAdmins have full access to all groups and entries within its associ ated realm Oracle Context.

OracleDBSecurityAdmins

(Called "Database Security Management" group in Release 9. 2 and earlier versions of Enterprise Security Manager)

DN: (cn=OracleDBSecurityAdmins,cn=OracleContext...)

Default owner: All group members.

During default realm Oracle Context c reation, Oracle Internet Directory Configuration Assistant sets up the following access rights/permissions for these group members:

  • All privileges in the OracleDBSecurity subtree
  • Modify privileges for membership in this group

OracleDBSecurityAdmins have permissions on all of the domains in the enterprise and perform the following tasks:

  • Sets Enterprise User Security configurations for the realm, such as the defa ult database-to-directory authentication method
  • Group owner administers the O racleDBSecurityAdmins group
  • Creates and deletes enterprise domains
  • Moves databases from one domain to another within the enterprise

OracleUserSecurityAdmins

(Called "Directory User Management" in Release 9.2 and earlier versions of Enterprise Security Mana ger)

DN: (cn=OracleUserSecurity Admins,cn=Groups,cn=OracleContext...)

Default owner: Th e user who created the identity management realm.

By default, an ACL is set at the directory root in Oracle Internet Directory that sets up the relevant permissions so OracleSecurityAdmins can administer Oracle user security. For example, by default, they can read wallet password hints and modify user passwords.

OraclePasswordAccessibleDomains

DN: (cn=OraclePasswordAccessibleDomains,cn=Groups,cn=Oracle Context...)

Default owner: Same as OracleDBSecurityAdmi ns

Group members are enterprise domains, which contain databases enabled for password-author ized enterprise users.

About Using Shared Schemas for Enterprise User Security

The following sections describe shared schemas, and how to set them up:

Overview of Shared Schemas Used in Enterprise User Security

Users do not necessarily require individual accounts or schemas set up in each database. Alternatively, they can connect to a shared schema and be granted access to objects that ar e associated with target applications. For example, suppose that users Tom, Dick, and Harriet require access to the Payroll applicati on on the Finance database. They do not need to create unique objects in the database, and therefore do not need their own schemas, b ut they do need access to the objects in the Payroll schema.

Oracle Database supports mappi ng multiple users stored in an enterprise directory to a shared schema on an individual database. This separation of users from schem as reduces administration costs by reducing the number of user accounts on databases. It means that you do not need to create an acco unt for each user (user schema) in addition to creating the user in the directory. Instead, you can create a user in the enterprise d irectory, and map that user to a shared schema which other enterprise users can also be mapped to. For example, if Tom, Dick and Harr iet all access both the Sales and the Finance databases, you do not need to create an account for each user on each of these database s. Instead, you can create a single shared schema on each database, such as GUEST, that all three users can access. Then individual access to objects in the Sales or Finance database can be granted to these three users by using enterprise roles. A typic al environment can have up to 5,000 enterprise users mapped to one shared schema and each user can be assigned a set of enterprise ro les.

Oracle recommends that you create a separate shared schema that contains no objects to use as an entry point. Then grant access to application objects in other schemas through enterprise roles. Otherwise, application ob jects can be inadvertently or maliciously deleted or altered.

In summary, shared schemas pr ovide the following benefits:

How Shared Schemas Are Configured for Enterprise Users

To configure shared schemas, the local database administrator (DBA) must create at least one database schema in a dat abase. Enterprise users can be mapped to this schema.

In the following example, the adminis trator creates a shared schema and maps users to it:

  1. The administrator creates a global shared schema called EMPLOYEE and the global role HRMANAGER on th e HR database.
  2. The administrator uses Enterprise Security Manager to cr eate and manage enterprise users and roles in the directory. For example, the administrator creates enterprise user Harriet and an en terprise role named MANAGER. The administrator then assigns the HR database global role of HRMANAGER to the enterprise role MANAGER.
  3. The administrator assigns enterp rise roles to enterprise users in the directory. For example, the administrator assigns the enterprise role MANAGER to H arriet.
  4. The administrator uses Enterprise Security Manager to map the u ser Harriet in the directory to the shared schema EMPLOYEE on the HR database.

When Harriet connects to the HR database, she is automatically connected to the EMPLOYEE schema and is given the global role of HRMANAGER. Multiple enterprise users can be mapped to the same shared schema. For example, the enterprise security administrator can create another enterprise user Scott and map Scott to the EMPLOYEE schema. From t hat point on, both Harriet and Scott automatically use the EMPLOYEE schema when connecting to the HR database, but each can have different roles and can be individually audited.
See Also:

Oracle Database Security Guide for more information about auditin g.

How Enterprise Users Are Mapped to Schemas

Global schemas (those created with CREATE USER IDENTIFIED GLOBALLY AS '') can be owned by one enterprise user (exclusive schema ) or shared among multiple enterprise users (shared schema). The mapping between a single enterprise user and his or her exclusive sc hema is stored in the database as an association between the user DN and the schema name. The mapping between enterprise users and a shared schema is done in the directory by means of one or more mapping objects. A mapping object is used to map the distinguished name (DN) of a user to a database schema that the user will access. You cr eate a mapping object by using Enterprise Security Manager. This mapping can be one of the following:

  • Entry-level (full DN) mapping

    This method assoc iates the DN of a single directory user with a particular schema on a database. It results in one mapping entry for each user.

  • Subtree-level (partial DN) mapping

    This method lets multiple enterprise users share part of their DN to access the same shared schema. This method is useful if multipl e enterprise users are already grouped under some common root in the directory tree. The subtree that these users share can be mapped to a shared schema on a database. For example, you can map all enterprise users in the subtree for the engineering division to one s hared schema, BUG_APP_USER, on the bug database. Note that the root of the subtree is not mapped to the specified schema.

    When an enterprise user connects to a database, the database retrieves a DN for the user, either from the network (in the case of SSL) or from the directory (in the case of password- and Kerberos-authenticated enterprise users).

    < a name="1006849">

    When determining which schema to connect the user to, the database uses the user DN and the fol lowing precedence rules:

    1. It looks for an exclu sive schema locally (in the database).
    2. If it does not find an exclusive schema locally, then it searches the directory. Within the directory, it looks under the server entry, first for an entry-level mapp ing, then for a subtree-level mapping.
    3. If it does not find a mapping en try under the server entry, then it looks under the enterprise domain entry, first for an entry-level mapping, then for a subtree-lev el mapping.
    4. If it does not find an exclusive schema locally, or an appl icable mapping entry in the database, then the database refuses the connection. Otherwise, the database connects the user to the appr opriate schema.

For example, suppose that Harriet is trying to connect to t he HR database, but the database does not find Harriet's exclusive schema (in the database). In this case, the following steps occur:

  1. The HR database looks up a user schema mappin g with Harriet's DN in the directory. The directory has a mapping of Harriet to the shared schema EMPLOYEE and returns t his schema.
  2. The database logs Harriet in and connects her to the EMPLOYEE schema.
  3. The database retrieves this user's global roles for this database from the directory.
  4. The database also retrieves from its own tables any local roles and privileges associated with the database schema to which the user is mapped.
  5. The database uses both the global and the local roles to determine the information that the user can access.

Continuing this example, assume that the enterprise role MANAG ER contains the global roles ANALYST on the HR database, and USER on the Payroll database. When Harr iet, who has the enterprise role MANAGER, connects to the HR database, she uses the schema EMPLOYEE on that database.

  • Her privileges on the HR database are de termined by:
    • The global role ANALYST
    • Any local roles and privileges associated with the EMPLOYEE schem a on the HR database
  • When Harriet connects to the Payroll database, her privileges are determined by:
    • The global role USER
    • Any local roles and privileges associated with the EMPLOYEE schema on the Payroll database

You can grant privileges to a specified gr oup of users by granting roles and privileges to a database schema. Every user sharing such a schema gets these local roles and privi leges in addition to personal enterprise roles. However, you should exercise caution when doing this, because every user who is mappe d to this shared schema can exercise the privileges assigned to it. Accordingly, Oracle does not recommend granting roles and privile ges to a shared schema.

See Also:

"Task 1: Create Global Schemas and Global Roles in the Database" for detailed information about how to create shared schemas for enterprise user s.

About Using Current User Database Links for Enterprise User Security

Oracle Database supports current user database links over an SSL-authenticated network conn ection. Current user database links let you connect to a second database as yourself, or as another user when used from within a stor ed procedure owned by that user. Such access is limited to the scope of the procedure. The security advantage of current user databas e links is that the other user's credentials are not stored in the database link definition, and are not sent across the network conn ection between databases. Instead, security of these links is based on mutual trust, mutual authentication, and a secure network conn ection between the databases themselves.

For example, a current user database link lets Har riet, a user of the Finance database, procedurally access the Accounts Payable database by connecting as the enterprise user Scott.

For Harriet to access a current user database link to connect to the schema Scott, Scott mus t be a global schema (created as IDENTIFIED GLOBALLY) in both databases. Harriet, however, can be a user identified in o ne of three ways:

  • By a password
  • GLOBALLY
  • EXTERNALLY

    • To create Scott as a global user in the first database, Finance, you must enter

    CREATE USER Scott IDENTIFIED GLOBALLY as 'CN=Scott,O=nmt'

    so that Scott has an exclusive schema. Then Scott can map to a shared schema in the second database, Accounts Payable. In order for the current user database link to work, the schema created for Scott in the first database cannot be shared wit h other users.

    Current user database links operate only between trusted databases within a single enterprise domain--databases within the domain trust each other to authenticate users. You specify an enterprise domain as tru sted by using Enterprise Security Manager. When you use Enterprise Security Manager to enable current user database links for a domai n, they will work for all databases within that domain. However, each database in the domain must have its own PKI credentials and us e SSL to authenticate to the other databases. To specify a database as untrusted that is part of a trusted enterprise domain, use the PL/SQL package DBMS_DISTRIBUTED_TRUST_ADMIN. To obtain a list of trusted servers, use the TRUSTED_SERVERS view.

    Note:

    Oracle Advanced Security does not support RADIUS authentication over database links.

    See Also:

    Enterprise User Security Deployment Considerations

    Consider the following issues before deploying Enterprise User Security:

    Security Aspects of Centralizing Security Credentials

    Beyond the general benefits that flow from the centralization of enterprise users and their associated credentials, there are a number of security-related benefits and risks that should be reviewed.

    Security Benefits Associated with Centralized Security Credential Ma nagement

    Centralizing management makes it easier and faster to admin ister users, credentials, and roles, and to quickly revoke a user's privileges on all applications and databases across the enterpris e. With centralized management, the administrator can delete a user in one place to revoke all global privileges, minimizing the risk of retaining unintended privileges.

    Centralizing management makes it possible to centraliz e an organization's security expertise. Specialized, security-aware administrators can manage all aspects of enterprise user security , including directory security, user roles and privileges, and database access. This is a substantial improvement over the traditiona l model, where DBAs are typically responsible for everything on the databases they manage, including security.

    Security Risks Associated with Centralized Security Credential Management

    While Oracle Internet Dir ectory is a secure repository, there is a security challenge and inherent risk in centralizing credentials in any publicly accessible repository. Although centralized credentials can be protected at least as securely as distributed credentials, the very nature of ce ntralization increases the consequences of inadvertent credential exposure to unauthorized parties. It is therefore imperative to lim it the privileges of administrators, to set restrictive Access Control Lists (ACLs) in the directory, and to implement good security practices in the protection of security credentials when they are temporarily outside of the directory.

    Security of Password-Authenticated Ent erprise User Database Login Information

    In all secure password-based authentication methods, a server authenticates a client with a password verifier, typically a hashed version of the password that mu st be rigorously protected. Password-based authentication to an Oracle database is no different. There is a password verifier, and it must be protected as well. This is true if the verifier is stored locally in the database or centrally in the directory. Note that a password verifier cannot be used to derive its original password.

    An enterprise user's dat abase password can be stored in a central directory service for access by multiple databases. It can be viewed and shared by all trus ted databases to which the user has access. Although the password verifier stored in the directory is not the cleartext password, it is still necessary to protect it from casual or unauthorized access. It is therefore extremely important to define password-related ACLs in the directory that are as restrictive as possible, while still e nabling necessary access and usability. (Note that Oracle Database supports all verifier types that are supported by Oracle Internet Directory.)

    Oracle tools help set up ACLs in the directory to protect these password verifi ers during identity management realm creation. The approach that Oracle recommends is intended to balance security and usability cons iderations. If you require maximum security and can set up wallets for all users, you should require only SSL connections from users to databases. This SSL-only approach circumvents the entire directory password protection issue.

    The following sections provide more information about trusted databases and protecting database password verifiers in the direc tory.

    Wha t is Meant by Trusted Databases

    SSL provides strong authentication s o databases are ensured of each others identity. With password-authenticated Enterprise User Security where database password verifie rs are stored centrally in a directory and shared among multiple databases, each database that allows password-authenticated enterpri se users to log in must be a trusted database. Each database has access to the shared password verifiers so it is important that each database can be trusted to observe the following security precautions:

    • Each database must be trusted to protect itself from tampering with the server code so a malicious user cannot misuse the d atabase identity to gain access to password verifiers in the directory.
    • Each d atabase must be trusted to protect its PKI and other credentials from theft so a malicious user cannot use them to gain access to the password verifiers stored in the directory.

    Protecting Database Password Verifiers

    < p class="BP">The OraclePasswordAccessibleDomains group in each identity management realm is created automatically when the realm is c reated, and can be managed by using Enterprise Security Manager. Enterprise domains with member databases that must view users' datab ase password verifiers in the directory are placed into this group.

    For a selected realm, d etermine which databases can accept password-authenticated connections. Use Enterprise Security Manager to place the domains containi ng those databases into the OraclePasswordAccessibleDomains group. An ACL on the user subtree permits access to the directory attribu te that holds the password verifier used by the database.

    All other users are denied access to this attribute. An ACL that prevents anonymous read access to the password verifier attributes is at the root of the directory tr ee.

    Note that for usability, by default the OracleDefaultDomain is a member of the OraclePa sswordAccessibleDomains group. It can be removed, if desired.

    See Also:

    Considerations f or Defining Database Membership in Enterprise Domains

    Consider the f ollowing criteria when defining the database membership of a domain:

    • Current user database links operate only between databases withi n a single enterprise domain. Use of these links requires mutual trust between these databases and between the DBAs who administer them.
    • Accepted aut hentication types for enterprise users are defined at the domain level. Database membership in a domain should therefore be defined a ccordingly. If one or more databases are intended to only support SSL-based certificate authentication, they cannot be combined in th e same domain with password-authenticated databases.
    • Enterprise roles are defi ned at the domain level. To share an enterprise role across multiple da tabases, the databases must be members of the same domain.

    Considerations for Choosing Authentication Types between Clients, Databases, and Directories for Enterprise User Security

    Enterprise User Securit y supports the authentication types listed in Table 11-3 for connections between clients, dat abases, and directories.

    Table 11-3 Enterprise User Security: Supported Authentication Types for Connections between Clients , Databases, and Directories
    Connection Supported Authentication Types

    Clients-to-Databases

    Passwords, S SL, and Kerberos

    Databases-to-Databases (Current User Database Links)

    SSL only

    < /td>

    Databases-to-Directo ries

    SSL and Passwords

    However, some combinations of authentication types for connections make more sense than others. For example, it is unusual to require a high level of security for client-to-database connections by using SSL for all user connections, but then configuring the database to authenticate to the directory by using passwords. Although this configuration is supported, it does not p rovide consistent security for connections. Ideally, the database-directory connection should be at least as secure as that between u sers and databases.

    Typical Configurations

    The following combinations of auth entication types between clients, databases, and directories are typical:

    • Password authentication for all connections with no need for current user database links
    • SSL authentication for all connections
    • Kerberos authent ication for client-to-database connections, and password authentication for database-to-directory connections