1 Introducing Enterprise User Security

1.1.2.1 How Oracle Internet Directory Implements Identity Management

Oracle Internet Directory uses the concept of identity management realms to organize information in the directory information tree (DIT), which is a hierarchical tree-like structure consisting of directory object entries. In a directory, each collection of information about an object is called an entry. This object may be a person, but it can also be information about a networked device, such as configuration information. 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.

1.1.2.2 Enterprise Users Compared to Database Users

Database users are 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@database_service_name
Enter Password:

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 controlled by local roles in each database.

In contrast, enterprise users are provisioned and managed centrally in an LDAP-compliant directory, such as Oracle Internet Directory, for database access. Enterprise users have a unique identity in the directory called the distinguished name (DN). When enterprise 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 USER statement in two different ways.

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

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

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

Alternatively, you can specify 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, multiple users can be mapped to a shared schema based on the mapping information set up and stored in Oracle Internet Directory.

CREATE USER username IDENTIFIED GLOBALLY;

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

CONNECT /@database_service_name

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

CONNECT username@database_service_name
Enter password:

When the database receives a connection request from an enterprise user, the database refers to the directory for user authentication and authorization (role) information.

1.1.2.3 About Enterprise User Schemas

Enterprise users can retain their individual database schemas (exclusive schemas) or share schemas if the enterprise security administrator maps them to a shared schema.

1.1.2.4 How Enterprise Users 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 that database, and optionally, a user name 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.

Enterprise 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 user name and password as part of the link definition. Current user database links allow enterprise users to access objects on remote databases without passing authentication information during link execution, or storing authentication 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 remote database only as an enterprise user.

1.1.2.5 How Enterprise Users Are Authenticated

Enterprise User Security supports the following authentication methods:

• • Password-based authentication

  • SSL-based authentication

  • Kerberos-based authentication

Each authentication method has advantages and disadvantages. Table 1-1 summarizes the criteria for selecting which authentication method is best for your Enterprise User Security implementation.

^Footnote 1 If third-party directory is Microsoft Active Directory, then when user passwords change, they must be changed in both Active Directory and in Oracle Internet Directory.

^Footnote 2 Must modify the Directory Integration Services agent to synchronize user PKCS #12 attributes.

^Footnote 3 If third-party directory is Microsoft Active Directory, then login to Windows gives you single sign-on login to databases. However, you must modify the Directory Integration Services agent for other third-party directories to synchronize the KrbPrincipalName attribute. This synchronization is automatic for Microsoft Active Directory.

1.1.3.1 Enterprise Users

An enterprise user is one who is defined and managed in a directory. Each enterprise user has a unique identity 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 reside only within a realm Oracle Context.

1.1.3.2 Enterprise Roles

An enterprise role is a directory object that acts like a container to hold one or more database global roles. Each global role is defined in a specific database where it is assigned privileges, but then it is managed in the directory by using enterprise roles. Enterprise users can be assigned an enterprise role, which determines their access privileges on databases. Figure 1-3 shows an example of an enterprise role called Manager under OracleDefaultDomain.

As an example, consider the enterprise role sales_manager, which contains 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 1-2 illustrates this example.

Figure 1-2 Example of Enterprise Roles

Description of "Figure 1-2 Example of Enterprise Roles"

An enterprise role can be assigned to one or more enterprise users. For example, you could assign the enterprise role sales_manager to a number of enterprise users who hold the same job. This information is protected 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, by virtue of the privileges on the schema to which the user connects.

Enterprise role entries are stored in enterprise domain subtrees. Each enterprise role contains information about associated global roles on each database server and the associated enterprise users. The enterprise domain administrator creates and manages enterprise roles by using Oracle Enterprise Manager.

1.1.3.3 Enterprise Domains

An enterprise domain is a group of databases and enterprise roles. An example of a domain could be the engineering division in an enterprise or a small enterprise itself. Figure 1-3 shows 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 Oracle Enterprise Manager, assigns enterprise roles to users and manages enterprise security.

An enterprise domain 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. All user-schema mappings entries contained in an enterprise domain apply to all databases in the domain. If you need to apply different user-schema mappings to individual databases, then use database server entries, which are discussed in the following section.

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 Oracle Enterprise Manager.

1.1.3.4 Database Server Entries

A database server entry (represented as "Sales" in Figure 1-3) is a directory entry containing 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-level mapping entries called user-schema mappings, which describe mappings between full or partial user DNs and database shared schema names. User-schema mapping entries are created by the database administrator by using Oracle Enterprise Manager.

Database administrators belong to the directory administrative group, OracleDBAdmins, which is also managed with Oracle Enterprise Manager. Only OracleDBAdmins or OracleContextAdmins group members can add or remove users from the OracleDBAdmins group. When a user registers a database in the directory, Database Configuration Assistant automatically puts the person who performs registration into the OracleDBAdmins group. The directory entry for this group is located under the database server entry in the DIT.

Figure 1-3 Related Entries in a Realm Oracle Context

Description of "Figure 1-3 Related Entries in a Realm Oracle Context"

1.1.3.5 User-Schema Mappings

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

1.1.3.6 Administrative Groups

An identity management realm contains administrative groups related to Enterprise User Security. Figure 1-3 shows these administrative groups in a realm in the triangle labeled "Groups." Each administrative group includes Access Control Lists (ACLs) that control access to the group itself. ACLs elsewhere in the directory may refer to these groups, which allows directory administrators access 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. However, this user can be removed.

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

1.1.3.7 Password Policies

Password policies are a set of rules that apply to all user passwords in an identity management realm. Password policies include settings for password complexity, minimum password length, and the like. They also include account lockout and password expiration settings.

A password policy entry is defined in Oracle Internet Directory for every identity management realm. Password policies in Oracle Internet Directory are standard Oracle Internet Directory entries that can be used by Oracle Database for Enterprise User Security.

Oracle Internet Directory ensures that all enterprise user passwords meet the rules specified in the password policy entry for the realm. The database communicates with Oracle Internet Directory when authenticating an enterprise user. It requests Oracle Internet Directory to report any password policy violations. If the database gets a policy violation response from Oracle Internet Directory, then it flashes the appropriate warning or error message to the user.

The database reports the following events:

• It flashes a warning when the user password is about to expire and displays the number of days left for the user to change his or her password.

• It flashes a warning when the password has expired and informs the user about the number of grace logins that remain.

• It displays an error when the user password has expired and the user does not have any grace logins left.

• It displays an error when the user account has been locked due to repeated failed attempts at login.

• It displays an error if the user account has been disabled by the administrator.

• It displays an error if the user account is inactive.

Although the database reads the user account status from Oracle Internet Directory to check for password policy violations, it does not update user account status in Oracle Internet Directory. For example, a failed enterprise user login attempt to the database is not updated in Oracle Internet Directory.

1.5.1.1 Security Benefits Associated with Centralized Security Credential Management

Centralizing management makes it easier and faster to administer users, credentials, and roles, and to quickly revoke a user's privileges on all applications and databases across the enterprise. 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 centralize 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 traditional model, where DBAs are typically responsible for everything on the databases they manage, including security.

1.5.1.2 Security Risks Associated with Centralized Security Credential Management

While Oracle Internet Directory 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 centralization increases the consequences of inadvertent credential exposure to unauthorized parties. It is therefore imperative to limit 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.

1.5.2.1 What Is Meant by Trusted Databases

SSL provides strong authentication so databases are ensured of each others identity. With password-authenticated Enterprise User Security where database password verifiers are stored centrally in a directory and shared among multiple databases, each database that allows password-authenticated enterprise 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 database identity to gain access to password verifiers in the directory.

• Each database 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.

1.5.2.2 Protecting Database Password Verifiers

The OraclePasswordAccessibleDomains group in each identity management realm is created automatically when the realm is created, and it can be managed by using Oracle Internet Directory tools like the Oracle Internet Directory Self-Service Console. Enterprise domains with member databases that must view users' database password verifiers in the directory are placed in this group.

For a selected realm, determine which databases can accept password-authenticated connections. Use Oracle Internet Directory Self-Service Console to place the domains containing those databases into the OraclePasswordAccessibleDomains group. An ACL on the user subtree permits access to the directory attribute 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 tree.

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

1.5.4.1 Typical Configurations

The following combinations of authentication 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 authentication for client-to-database connections, and password authentication for database-to-directory connections