How Enterprise Users Are Mapped to Schemas

Global schemas (those created with CREATE USER IDENTIFIED GLOBALLY AS '') can be owned by one enterprise user (exclusive schema) or shared among multiple enterprise users (shared schema). The mapping between a single enterprise user and his or her exclusive 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 Oracle Enterprise 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:

    1. It looks for an exclusive schema locally (in the database).

    2. If it does not find an exclusive schema locally, then it searches the directory. Within the directory, it looks under the database server entry, first for an entry-level mapping, and then for a subtree-level mapping.

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

    4. 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:

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

  2. The database logs Harriet in and connects her to the EMPLOYEE schema.

  3. The database retrieves this user's global roles for this database from the directory.

  4. The database also retrieves from its own tables any local roles and privileges associated with the database schema to which the user is mapped.

  5. The database uses both the global and the local roles to determine the information that the user can access.

Continuing this example, assume that the enterprise role 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: