| Oracle® Database Advanced Security Administrator's Guide 10g Release 1 (10.1) Part Number B10772-01 |
|
|
View PDF |
| Oracle® Database Advanced Security Administrator's Guide 10g Release 1 (10.1) Part Number B10772-01 |
|
|
View PDF |
Enterprise User Security, a critical 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 Enterprise User Security is and how it works:
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:
Administrators must keep user information up to date and secure for the entire enterprise. This task becomes more difficult as the number of applications and users increases. Typically, each user has multiple accounts on different databases, which means each 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 database accounts, administrators must devote substantial resources to user administration. Common information used by multiple applications, 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 changes jobs, that user's privileges should be changed the same day in order to guard against their misuse. However, in a large enterprise, if you have too many user accounts distributed over multiple databases, an administrator may be unable to make such timely changes. 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 compromised password a greater security risk). All of these user efforts to keep track of their multiple passwords can compromise the security of the enterprise.
Enterprise User 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, where 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 Oracle security architecture, which uses the Oracle Identity Management infrastructure as its foundation.
Text description of the illustration asoag038.gif
Users benefit from Enterprise User Security through single sign-on (SSO) or single password authentication, depending on the configuration chosen by the administrator. Using single sign-on, users need to authenticate only once and subsequent authentications take place transparently. This functionality requires SSL, and should not be confused with OracleAS Single Sign-On, a component of Oracle Identity Management infrastructure.
Single password authentication lets users authenticate to multiple databases with a single global password although each connection requires a unique authentication. The password is securely stored in the centrally located, 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 and manage, and by eliminating the overhead of setting up SSL.
Enterprise User Security requires Oracle Internet Directory 10g (9.0.4). Other LDAP-compliant directory services are supported by using Oracle Internet Directory Integration Platform to synchronize them with Oracle Internet Directory.
This section contains the following topics:
| See Also:
[Oracle Internet Directory Administrator's Guide, for information about using Oracle Directory Integration Platform with other directories. |
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.
An identity management 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 applications of the enterprise may belong to another realm. Use of different realms enables an enterprise to isolate user populations and enforce different administrative policies, such as password policies or naming policies, in each realm.
Each identity management realm has a realm-specific Oracle Context (realm Oracle Context) that stores Oracle product information for that realm. A realm Oracle Context stores application data, how users are named and located, how users must be authenticated, group locations, and privilege assignments--all specific to the particular identity management realm in which the realm Oracle Context is located.
See Also:
|
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/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 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.
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/password@database_service_name
When the database receives a connection request from an enterprise user, the database refers to the directory for user authentication and authorization (role) information.
See Also:
|
Enterprise users can retain their individual database schemas (exclusive schemas) or share schemas if the enterprise security administrator maps them to a shared schema.
If users want to retain their individual schemas in the databases that they access, then
Creating separate accounts for each 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.
To receive the real benefit of the enterprise user solution, you can use shared schemas for your enterprise users. For this strategy
Mapping enterprise users to a generic, shared schema on each of the databases that 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.
| See Also:
"About Using Shared Schemas for Enterprise User Security" for more information about creating and using shared schemas for enterprise users. |
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 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.
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 username 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.
See Also:
|
Enterprise User Security supports the following authentication methods:
Each authentication method has advantages and disadvantages. Table 11-1 summarizes the criteria for selecting which authentication method is best for your Enterprise User Security implementation.
| Password Authentication | SSL Authentication | 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 authenticators, and authentication forwarding. |
|
Retains users' current authentication methods. |
Initial configuration maybe more difficult because PKI credentials must be generated for all users. (Dependent on administrators' PKI knowledge) |
Initial configuration maybe more difficult because Kerberos 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. |
Compatible with either a two-tier or multitier environment. |
Compatible 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 Database 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 user 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-party directories to store users if synchronized with Oracle Internet Directory.Foot 2 |
Can use third-party directories to store users if synchronized with Oracle Internet Directory.Foot 3 |
|
Note: Enterprise User Security supports three-tier environments. Oracle Database 10g proxy authentication features enable (i) proxy of user names and passwords through multiple tiers, and (ii) proxy of X.509 certificates and distinguished names through multiple tiers. |
See Also:
|
In a directory, each collection of information about an object is called 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 uniquely 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 complete 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:
An enterprise user is one that 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 only reside within a realm Oracle Context.
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 under the OracleDefaultDomain.
An enterprise role can consist of one or many global roles, each one of which is defined in a specific database. 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.
Text description of the illustration asoag033.gif
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.
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 Enterprise Security Manager.
| See Also:
"Administering Enterprise Roles" for information about using Enterprise Security Manager to create and manage enterprise roles. |
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 11-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 Enterprise Security 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 Enterprise Security Manager.
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-level mapping entries that contain mapping information between full or partial user DNs and Oracle shared schema names (user-schema mappings). 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 administrators for a specific database. The directory entry for this group is located under the database server entry in the DIT.
Text description of the illustration asoag032.gif
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 schema when they connect to the database. User-schema mapping entries can apply only to one database or they can apply to all databases in a domain, depending on where they reside in the realm Oracle Context.
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 administrative group includes an Access Control Lists (ACLs) that controls 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, but can be removed.
The relevant administrative groups in a realm are described in Table 11-2.
The following sections describe shared schemas, and how to set them up:
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 are associated with target applications. For example, suppose that users Tom, Dick, and Harriet require access to the Payroll application on the Finance database. They do not need to create unique objects in the database, and therefore do not need their own schemas, but they do need access to the objects in the Payroll schema.
Oracle Database supports mapping multiple users stored in an enterprise directory to a shared schema on an individual database. This separation of users from schemas reduces administration costs by reducing the number of user accounts on databases. It means that you do not need to create an account for each user (user schema) in addition to creating the user in the directory. Instead, you can create a user in the enterprise directory, and map that user to a shared schema which other enterprise users can also be mapped to. For example, if Tom, Dick and Harriet all access both the Sales and the Finance databases, you do not need to create an account for each user on each of these databases. 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 typical environment can have up to 5,000 enterprise users mapped to one shared schema and each user can be assigned a set of enterprise roles.
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 objects can be inadvertently or maliciously deleted or altered.
In summary, shared schemas provide the following benefits:
To configure shared schemas, the local database administrator (DBA) must create at least one database schema in a database. Enterprise users can be mapped to this schema.
In the following example, the administrator creates a shared schema and maps users to it:
EMPLOYEE and the global role HRMANAGER on the HR database.MANAGER. The administrator then assigns the HR database global role of HRMANAGER to the enterprise role MANAGER.MANAGER to Harriet.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 that 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 auditing. |
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 schema 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 create a mapping object by using Enterprise Security Manager. This mapping can be one of the following:
This method associates the DN of a single directory user with a particular schema on a database. It results in one mapping entry for each user.
This method lets multiple enterprise users share part of their DN to access the same shared schema. This method is useful if multiple 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 shared 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).
When determining which schema to connect the user to, the database uses the user DN and the following precedence rules:
For example, suppose that Harriet is trying to connect to the HR database, but the database does not find Harriet's exclusive schema (in the database). In this case, the following steps occur:
EMPLOYEE and returns this schema.EMPLOYEE schema.Continuing this example, assume that the enterprise role MANAGER contains the global roles ANALYST on the HR database, and USER on the Payroll database. When Harriet, who has the enterprise role MANAGER, connects to the HR database, she uses the schema EMPLOYEE on that database.
You can grant privileges to a specified group of users by granting roles and privileges to a database schema. Every user sharing such a schema gets these local roles and privileges in addition to personal enterprise roles. However, you should exercise caution when doing this, because every user who is mapped to this shared schema can exercise the privileges assigned to it. Accordingly, Oracle does not recommend granting roles and privileges 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 users. |
Oracle Database supports current user database links over an SSL-authenticated network connection. Current user database links let you connect to a second database as yourself, or as another user when used from within a stored procedure owned by that user. Such access is limited to the scope of the procedure. The security advantage of current user database links is that the other user's credentials are not stored in the database link definition, and are not sent across the network connection between databases. Instead, security of these links is based on mutual trust, mutual authentication, and a secure network connection between the databases themselves.
For example, a current user database link lets Harriet, 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 must be a global schema (created as IDENTIFIED GLOBALLY) in both databases. Harriet, however, can be a user identified in one of three ways:
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 with 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 trusted by using Enterprise Security Manager. When you use Enterprise Security Manager to enable current user database links for a domain, they will work for all databases within that domain. However, each database in the domain must have its own PKI credentials and use 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.
See Also:
|
Consider the following issues before deploying Enterprise User Security:
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.
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.
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.
In all secure password-based authentication methods, a server authenticates a client with a password verifier, typically a hashed version of the password that must 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 database password can be stored in a central directory service for access by multiple databases. It can be viewed and shared by all trusted 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 enabling 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 verifiers during identity management realm creation. The approach that Oracle recommends is intended to balance security and usability considerations. 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 directory.
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:
The OraclePasswordAccessibleDomains group in each identity management realm is created automatically when the realm is created, and can be managed by using Enterprise Security Manager. Enterprise domains with member databases that must view users' database password verifiers in the directory are placed into this group.
For a selected realm, determine which databases can accept password-authenticated connections. Use Enterprise Security Manager 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 the OracleDefaultDomain is a member of the OraclePasswordAccessibleDomains group. It can be removed, if desired.
See Also:
|
Consider the following criteria when defining the database membership of a domain:
Enterprise User Security supports the authentication types listed in Table 11-3 for connections between clients, databases, and directories.
| Connection | Supported Authentication Types |
|---|---|
|
Clients-to-Databases |
Passwords, SSL, and Kerberos |
|
Databases-to-Databases (Current User Database Links) |
SSL only |
|
Databases-to-Directories |
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 provide consistent security for connections. Ideally, the database-directory connection should be at least as secure as that between users and databases.
The following combinations of authentication types between clients, databases, and directories are typical:
|
 Copyright © 1996, 2003 Oracle Corporation All Rights Reserved. |
|