Applying EUS

From an application-building perspective, EUS is attractive. Nothing special has to be done. Enterprise Users are transparent to the application’s client connection. That is, the application connects using a username and password, and the application doesn’t specify, hint, or in any way control whether it’s connected to a “regular” database user or an Enterprise User. It doesn’t matter whether the user is connected directly to the database or whether the application connects to the database on the user’s behalf (proxy or otherwise). This is a wonderful feature because it’s the basis for backward compatibility.

Creating the Enterprise User

There are two ways to create your Enterprise Users. Chapter 6 shows how you can use the Delegated Administration Services web interface known as OiDDAS. Your second choice is to use the Enterprise Security Manager web console. In Oracle Database 10g, the Enterprise Security Manager (ESM) program is a client-server program that allows you only to view users and add/revoke authorizations; in previous releases, you could add, modify, and delete users from this tool. To create new users or delete existing ones, the Enterprise Security Manager web console can be used. The web console can be found by selecting the ESM Console URL from the File menu of the ESM (client-server) program.

To create users, you have to log on to the directory as an administrator. By default, the directory administrator is the orcladmin user. By selecting the Users and Groups tab, you’ll see two subtabs, User and Group. Select the User subtab and click the Create button to see the administration screen for creating a new user. Figure 5-3 shows the Create User screen that can be used to add new directory users.

Figure 5-3: The Enterprise Security Manager web console can be used to manage the creation and deletion of Enterprise Users.

Unfortunately, the web console doesn’t allow you to administer anything else in the database-directory relationship. For example, you can’t see the databases that are registered, or any mapping or authorization information for the users. To access those elements, you have to use the ESM client-server program.

The Connection Process

When an Enterprise User logs on to the database, the database doesn’t immediately know if the user is a directory-authenticated user or a database-authenticated user. On login, the database first searches for a database user account that matches the username presented. Assuming the password is correct, if no username entry is found, the database checks the value of the ldap_directory_access parameter. If it’s set to NONE, then the database returns an ORA-1017: invalid username/password message:

system@KNOX10g> -- disable directory access system@KNOX10g> ALTER SYSTEM SET ldap_directory_access=NONE SCOPE=MEMORY; System altered. system@KNOX10g> -- connect as an Enterprise User system@KNOX10g> CONN knox/oracle10g ERROR: ORA-01017: invalid username/password; logon denied

Tip 

By setting the ldap_directory_access to NONE you can quickly disable directory access if there is a security risk.

If the ldap_directory_access parameter is set to either PASSWORD or SSL, the database assumes this is a directory-authenticated user and queries the directory for the user entry matching this user’s name. The user’s name is a specific subcomponent of the distinguished name and is referred to as the nickname. The default nickname is the common name, or cn, and this is one of the configurable components you can manage during the initial directory setup. If the user isn’t a database user or a directory user, a different error is raised:

system@KNOX10g> -- enable directory access system@KNOX10g> ALTER SYSTEM   2    SET ldap_directory_access=PASSWORD SCOPE=MEMORY; System altered. system@KNOX10g> -- connect as a user that does not exist in DB or directory system@KNOX10g> CONN aldfjaslkjd/aslkd ERROR: ORA-28273: No mapping for user nickname to LDAP distinguished name exists. 

When the appropriate entry is found, the password presented will be authenticated against the password stored in the LDAP server:

C:\>sqlplus knox/oracle10g SQL*Plus: Release 10.1.0.2.0 - Production on Fri Apr 2 21:44:56 2004 Copyright (c) 1982, 2004, Oracle.  All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP and Data Mining options app_public@KNOX10g>

The user was able to log on, but it looks as if the database has put them into the wrong schema! Actually, it hasn’t because there is no KNOX database schema. If there were a KNOX schema, the initial log in would have worked (assuming the password was correct).

When you create an Enterprise User, you have to define a database schema for them. This mapping determines the schema to which the user will be attached. In the above example, there is a mapping for the KNOX Enterprise User to the APP_PUBLIC database schema. Setting up the user-schema mapping is a two-step process. The first step is to create the database schema; the second step is to define the mapping within the directory.