Policy Server Guides › Policy Server Configuration Guide › Directory Mapping › Directory Mapping Examples

Directory Mapping Examples

Multiple directory mappings are required to authenticate and authorize users that have access to network resources. The following figure illustrates a simple case where multiple directory mappings are required.

In the example, there are three realms that have separate authorization user directories and one realm that does not have its own authorization user directory. User authentication information is maintained in two distinct authentication directories. If the requested resource is in the Marketing, Engineering, or Quality Assurance realms, the Policy Server uses one of the authentication directories. The decision is based on the directory in the session ticket information.

You can use identity mapping to map the directories using complex user search criteria.

More information:

Realms

Employee Accesses an Engineering Realm Resource

In the previous graphic showing multiple user directories, the authentication data for a regular employee resides in the central authentication user directory. When the employee tries accessing a resource in the engineering realm, the employee is authenticated.

The Policy Server recognizes that the engineering realm uses its own authorization directory. The Policy Server looks for the directory mapping between the central authentication user directory and the engineering realm authorization user directory. The server then maps the user identity to the authorization directory. The Policy Server can now verify whether the employee has access to the requested realm.

Temporary Employee Accesses a Quality Assurance Realm Resource

In the previous graphic showing multiple user directories, the authentication data for a temporary employee resides in the temporary employee authentication user directory. The employee tries accessing a resource in the sales realm. The sales realm is not associated with its own authorization directory.

The Policy Server authenticates the employee in theauthentication directory, then checks to see if a directory mapping is set up. Since the sales realm does not have its own authorization directory, the Policy Server tries to authorize the employee against the same directory where the employee was authenticated.

Directory Mapping by Universal ID

In the previous figure showing multiple user directories, the authentication data for an employee resides in the central authentication user directory. The employee attempts to access a resource in the Engineering realm. After the employee is authenticated, the Policy Server uses a directory mapping to find the employee in the Engineering authorization directory. The user is identified by the employee Universal ID. See the following figure.

In the previous figure, assume that the directory mapping uses a Universal ID. To find a matching universal ID in the authorization directory, the Policy Server uses the universal ID attribute that is defined in authentication directory. After locating the universal ID in the authorization directory, the policy processing can finish and determine whether the user can access the protected resource.

Directory Mapping Case Sensitivity

Case-sensitive directories, such as an Oracle database, treat the values "ROBIN" and "robin" as two different user names. Other directories, such as an LDAP directory, are not case-sensitive and treat the values "Robin", "ROBIN", "robin", and "RobIn" as the same user name. A conflict can occur if the authentication directory is not case-sensitive, but the authorization directory is case-sensitive.

Authentication can fail because the authentication directory is case-sensitive. However, the user can recover by reentering the user name in the format that the directory requires. If the directory requires the user name to be in the format "Name", for example, the user can reenter the name correctly as "Robin". If authorization fails due to case-sensitivity, the Policy Server has no way to recover.

If the authorization directory is case-sensitive, change the format of the authenticated user name so that it matches the format that the authorization directory requires. If the authenticated user name is "RoBiN," but the authorization directory requires the format "Name", first change "RoBiN" to "Robin" and then authorize the user.

Identity Mapping by Complex User Search Criterion

Identity Mapping locates a user by relying on the session ticket information and the construction of the identity mapping entries.

The XPS function IDENTITY_MAP finds the Identity Mapping object by name. On finding a user in the target user directory by resolving its entries, returns the value of the attribute specified by the second parameter.

Example:

To get the last name of the user in the target user directory defined by the Identity Mapping named “target”, provide the following:

IDENTITY_MAP (“target”, last_name);