| Oracle® Database Enterprise User Administrator's Guide 10g Release 2 (10.2) Part Number B14269-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Database Enterprise User Administrator's Guide 10g Release 2 (10.2) Part Number B14269-01 |
|
|
PDF · Mobi · ePub |
Enterprise User Security is an important component of Oracle Database 10g Release 2 (10.2) Enterprise Edition. It enables you to address administrative and security challenges for a large number of enterprise database users. Enterprise users are those users that are defined in a directory. Their identity remains constant throughout the enterprise. Enterprise User Security relies on Oracle Identity Management infrastructure, which in turn uses an LDAP-compliant directory service to centrally store and manage users.
This chapter explains what Enterprise User Security is and how it works, in the following topics:
This overview of Enterprise User Security explains how it benefits an organization and how enterprise users authenticate and access resources across a distributed database system. 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 that each user must remember multiple passwords. The result is too many passwords for users to remember and too many accounts for administrators to effectively manage.
With thousands of users accessing database accounts, user administration requires substantial resources. Common information used by multiple applications, such as usernames, telephone numbers, and system roles and privileges, is typically fragmented across the enterprise. Such data increasingly becomes 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, large enterprises often have many user accounts distributed over multiple databases, and an administrator may be unable to make such timely changes.
Similarly, if your users have too many passwords, they may write them down, making them easy for others to copy. They may choose passwords that are easy to remember, making them easy for others to guess, or use the same password for multiple applications, risking wider consequences from a compromised password. All such user efforts to track multiple passwords can compromise enterprise security.
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 1-1 shows how Enterprise User Security fits into the Oracle security architecture, which uses the Oracle Identity Management infrastructure as its foundation.
Figure 1-1 Enterprise User Security and the Oracle Security Architecture
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, which 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) or higher. 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:
How Oracle Internet Directory Implements Identity Management
How Enterprise Users Access Database Resources with Database Links
How Enterprise Users Are Authenticated
See Also:
Oracle Internet Directory Administrator's Guide, for information about using Oracle Directory Integration Platform with other directoriesNote:
Microsoft Active Directory is supported only for Oracle databases on Windows platforms.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. The default nickname attribute, used to identify the login identity, is uid, and it is set in each identity management 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:
Oracle Internet Directory Administrator's Guide for information about Oracle Internet Directory and its architecture
"About Enterprise User Security Directory Entries" for information about Oracle Internet Directory entries that are used for Enterprise User Security
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:
Oracle Database Security Guide for more information about global users
Oracle Internet Directory Administrator's Guide for information about defining users in the directory
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
Create enterprise users in the directory, and
Create a global user schema for each user in each database that they access.
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
Create enterprise users in the directory,
Create a single shared schema in each database, and
Create a single shared schema mapping in Oracle Internet Directory.
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 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.
See Also:
"About Using Current User Database Links for Enterprise User Security" for detailed information about creating and using current user database links
Oracle Database Administrator's Guide for information about all of the different types of database links supported by Oracle Database
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.
Table 1-1 Enterprise User Security Authentication: Selection Criteria
| 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 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 Oracle Database 10g | Supports Oracle8i and later clients with Oracle Database 10g | Supports Oracle Database 10g clients and later with 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 DirectoryFoot 1 | Can use third-party directories to store users if synchronized with Oracle Internet DirectoryFoot 2 | Can use third-party directories to store users if synchronized with Oracle Internet DirectoryFoot 3 |
KrbPrincipalName attribute. This synchronization is automatic for Microsoft Active Directory.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:
Chapter 3, "Enterprise User Security Configuration Tasks and Troubleshooting" for information about configuring the various authentication types for enterprise user security
Oracle Database Security Guide, for information about using proxy authentication
In a directory, a 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 is stored as entries in the directory.
Each entry in the directory is uniquely identified by a 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 entriesThe following sections describe directory entries related to Enterprise User Security:
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.
Note:
When creating enterprise users in a 9.0.4 or later Oracle Internet Directory, use the tools that come with that 9.0.4 or later Oracle Internet Directory, such as Delegated Administration System (DAS) and the Enterprise Security Manager console. Even if your databases are 9i or 9iR2, do not use the 9i or 9iR2 Enterprise Security Manager GUI tool to create users in a 9.0.4 or later Oracle Internet Directory.Use only DAS-based tools that ship with Oracle Application Server 10g to create enterprise users in identity management realms. DAS-based tools include Enterprise Security Manager Console and Oracle Internet Directory Self-Service Console.
The entries described in the following sections can reside only within a realm Oracle Context.
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.
See Also:
Oracle Internet Directory Administrator's Guide for detailed information on password policies and their managementAn 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.
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 Enterprise Security Manager.
See Also:
"Roles: Administering Enterprise Roles" for information about using Enterprise Security Manager to create and manage enterprise rolesAn 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 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 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 Enterprise Security Manager.
Database administrators belong to the directory administrative group, OracleDBAdmins, which is also managed with the Enterprise Security Manager tool. 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.
See Also:
Table 1-2 for a description of the OracleContextAdmins group
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.
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.
Note:
Observe the following practices. Using other methods may break the security configuration 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 Context object ACLs are not supported.
Use only Oracle tools, such as Enterprise Security Manager, Enterprise Security Manager Console, and Database Configuration Assistant, to modify Enterprise User Security directory entries.
Table 1-2 Administrative Groups in a Realm Oracle Context
| Administrative Group | Description |
|---|---|
| OracleContextAdmins
(Called "Full Context Management" group in Release 9.2 and earlier versions of Enterprise Security Manager) |
DN: (cn=OracleContextAdmins,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 OracleContextAdmins have full access to all groups and entries within the associated realm Oracle Context. |
| OracleDBAdmins
(Accessed by way of the Administrators tab for database entries in Enterprise Security Manager) |
DN: (cn=OracleDBAdmins,cn=<database_entry_name>,cn=OracleContext...)
Default owner: None. Database Configuration Assistant automatically makes the user who registers a database in the directory a member of this group. Members of this group manage user-schema mappings specific to this database. Only users who are already members of this group or OracleContextAdmins can add or remove users from the OracleDBAdmins group. |
| OracleDBCreators
(Called "Database Registration Admins" in Release 9.2 and earlier versions of Enterprise Security Manager) |
DN: (cn=OracleDBCreators,cn=OracleContext...)
Default owner: OracleContextAdmins During default realm Oracle Context creation, Oracle Internet Directory Configuration Assistant sets up the following access rights/permissions for these group members:
OracleDBCreators create new databases and register them in the directory by using Database Configuration Assistant |
| 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 creation, Oracle Internet Directory Configuration Assistant sets up the following access rights/permissions for these group members:
OracleDBSecurityAdmins have permissions on all of the domains in the enterprise and perform the following tasks:
|
| OracleDomainAdmins | DN: (cn=OracleDomainAdmins,cn=<enterprise_domain_name>,
Default owner: The user creating or updating the domain. If a new context and OracleDefaultDomain are created, then the initial member will be the context creator. Members of the OracleDomainAdmins group have full privileges for the enterprise domain. They manage mappings, enterprise roles, and proxy permissions specific to the entire domain. You should be a member of OracleDomainAdmins (for the domain), OracleDBSecurityAdmins, or OracleContextAdmins to modify membership of this group. |
| OracleUserSecurityAdmins
(Called "Directory User Management" in Release 9.2 and earlier versions of Enterprise Security Manager) |
DN: (cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext...)
Default owner: The 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. |
| OraclePasswordAccessibleDomains | DN: (cn=OraclePasswordAccessibleDomains,cn=Groups,cn=OracleContext...)
Default owner: Same as OracleDBSecurityAdmins Group members are enterprise domains, which contain databases enabled for password-authorized enterprise users. |
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 the objects 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. Other enterprise users can also be mapped to that schema.
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 database. 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:
Shared schemas eliminate the need to have a dedicated database schema on each database for each enterprise user.
Each enterprise user can be mapped to a shared schema on each database the user needs to access. The user connects to the shared schema when the user connects to a database.
Shared schemas lower the cost of managing users in an enterprise.
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:
The administrator creates a global shared schema called EMPLOYEE and the global role HRMANAGER on the HR database.
The administrator uses Enterprise Security Manager to create and manage enterprise users and roles in the directory. For example, the administrator creates enterprise user Harriet and an enterprise role named MANAGER. The administrator then assigns the HR database global role of HRMANAGER to the enterprise role MANAGER.
The administrator assigns enterprise roles to enterprise users in the directory. For example, the administrator assigns the enterprise role MANAGER to Harriet.
The administrator uses Enterprise Security Manager to map the user 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 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 auditingGlobal 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:
Entry-level (full DN) mapping
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.
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 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:
It looks for an exclusive schema locally (in the database).
If it does not find an exclusive schema locally, then it searches the directory. Within the directory, it looks under the database server entry, first for an entry-level mapping, and then for a subtree-level mapping.
If it does not find a mapping entry under the server entry, then it looks under the enterprise domain entry, first for an entry-level mapping, and then for a subtree-level mapping.
If it does not find an exclusive schema locally or an applicable mapping entry in the database, then the database refuses the connection. Otherwise, the database connects the user to the appropriate schema.
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 events occur:
The HR database looks up a user schema mapping with Harriet's DN in the directory. The directory has a mapping of Harriet to the shared schema EMPLOYEE and returns this schema.
The database logs Harriet in and connects her to the EMPLOYEE schema.
The database retrieves this user's global roles for this database from the directory.
The database also retrieves from its own tables any local roles and privileges associated with the database schema to which the user is mapped.
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 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.
Her privileges on the HR database are determined by:
The global role ANALYST
Any local roles and privileges associated with the EMPLOYEE schema 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 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
Sometimes, an enterprise user needs to connect to a database as another user, temporarily having the target user's authorizations and privileges. This capability is particularly useful for midtier tools or applications, which often operate across various databases as enterprise users, their identities established as entries in Oracle Internet Directory. Such an application can maintain a single database connection while switching end user identities, thereby providing functionality in the name of each authorized user in turn.
Enterprise User Security 10g Release 2 (10.2) enhances the efficiency of the proxy mechanism by introducing a single-session model. The two-session proxy model required maintaining separate sessions for the proxy user and the target user. In the new model, only one session is maintained in the security context of the target user. This leads to an improvement in performance.
Enterprise User Security 10g Release 2 (10.2) allows greater granularity in assigning proxy permissions to enterprise users. Enterprise users can be individually granted permissions to proxy as local database users. The permissions no longer need to be associated with the user's shared schema in the database.
That you can assign proxy permissions individually to enterprise users means that the permissions can be more specific. Assigning permissions to a shared schema, on the other hand, forces you to assign the same permissions to all users who map to the schema. This can lead to unwarranted rights and privileges.
Enterprise user proxy permissions are created and stored in Oracle Internet Directory. A permission allows one or more enterprise users or groups to proxy as a target database user. Permissions can apply to specific databases or to all databases in the enterprise domain.
By default, domain administrators can manage proxy permissions in the directory for an enterprise domain. These permissions are configured and managed using Enterprise Security Manager.
See Also:
For more information on configuring enterprise user proxy permissions, see "Managing Proxy Permissions in Enterprise Domains"Setting up such proxying has several stages:
Identify all enterprise users who need permissions to proxy to various databases.
Identify all the target users in each such database.
Issue ALTER USER commands for each such target user, in the following form:
ALTER USER target_user GRANT CONNECT THROUGH ENTERPRISE USERS
The target_user can now be proxied to by the enterprise users that have proxy permissions in Oracle Internet Directory. Revoking proxy permission uses similar syntax, replacing GRANT with REVOKE.
See Also:
For the full
ALTER USER syntax, see Oracle Database SQL Reference
For Oracle Call Interface usage, see Oracle Call Interface Programmer's Guide
Grant proxy permissions to each enterprise user either individually or as a member of a group. See the section entitled "Managing Proxy Permissions in Enterprise Domains" in Chapter 4.
Note:
To establish a group representing those enterprise users who will proxy to the same database user, use Oracle Delegated Administration Services as described in the Oracle Identity Management Guide to Delegated Administration .With all four of the preceding steps accomplished, your identified enterprise users can proxy to any of the local database users you identified and associated with them. Two versions of the CONNECT command can be used. In (a), you supply the enterprise user's password in the command. In (b), you do not, relying instead on the password being in a wallet whose location was put in the sqlnet.ora file.
To establish an enterprise user proxy connection as a database user, use the following SQL*Plus command syntax, supplying the enterprise user's password:
CONNECT joeproxy[targetuser]/password@database_service_name
where you would replace joeproxy with the name of the enterprise user wishing to proxy as targetuser, replace targetuser with the name of the registered user of the target database, and replace password with the enterprise user's password. The square brackets are required.
Once these identities are validated, this connection request results in a single session, in which the proxy user operates in the target database as the target user. The identity of the original user is maintained through to the database, and the audit records can capture both the proxy and the target user's identity.
To connect as an enterprise user proxy for a database user without specifying a password, ensure that the sqlnet.ora file contains the location of the wallet holding that user's password. Then, use the following command syntax:
Note:
The regular proxy login mechanism using OCI calls can still be used. TheCONNECT syntax is a new alternative. For more information on the OCI call mechanism, refer to Oracle Database Security Guide.Although the enterprise user proxy permissions are assigned in Oracle Internet Directory, the database administrator can decide as to which local accounts are to be available as enterprise user proxy targets. The enterprise domain administrator can assign proxy permissions to only those targets that are available in the dba_proxies view of the database.
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:
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 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.
Note:
Oracle Advanced Security, an option to the Oracle Database Enterprise Edition, does not support RADIUS authentication over database links.See Also:
Oracle Database Heterogeneous Connectivity Administrator's Guide, for additional information about current user database links
Oracle Database SQL Reference, for more information about SQL syntax
PL/SQL Packages and Types Reference, for information about the PL/SQL package DBMS_DISTRIBUTED_TRUST_ADMIN
Oracle Database Reference, for information about the TRUSTED_SERVERS view
Oracle Database Advanced Security Administrator's Guide, Chapter 7, for information about configuring SSL for Oracle Net.
Oracle Database Advanced Security Administrator's Guide, Chapter 8, for information about creating wallets
Consider the following issues before deploying Enterprise User Security:
Security of Password-Authenticated Enterprise User Database Login Information
Considerations for Defining Database Membership in Enterprise Domains
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 the 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:
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.
The OraclePasswordAccessibleDomains group in each identity management realm is created automatically when the realm is created, and it 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 in 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, OracleDefaultDomain is a member of the OraclePasswordAccessibleDomains group. It can be removed, if desired.
See Also:
Oracle Internet Directory Administrator's Guide if you are not storing your users in the subtree of an identity management realm. This manual describes how to configure ACLs so password-authenticated users can connect to databases
Consider the following criteria when defining the database membership of a domain:
Current user database links operate only between databases within a single enterprise domain. Use of these links requires mutual trust between these databases and between the DBAs who administer them.
Accepted authentication types for enterprise users are defined at the domain level. Database membership in a domain should therefore be defined accordingly.
Note:
If one or more databases are intended to only support SSL-based certificate authentication, they cannot be combined in the same domain with password-authenticated databases.Enterprise roles are defined at the domain level. To share an enterprise role across multiple databases, the databases must be members of the same domain.
Enterprise User Security supports the authentication types listed in Table 1-3 for connections between clients, databases, and directories.
Table 1-3 Enterprise User Security: Supported Authentication Types 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 have a high level of security for client-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:
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
|
 Copyright © 2000, 2005, Oracle. All rights reserved. Legal Notices |
|