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 sample 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 based on the directory in the session ticket information.

In addition to mapping the directories using Universal ID and Identical DN, 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 CA SiteMinder® protected network described in the previous figure, a regular employee’s authentication data resides in the Central Authentication user directory, and the employee attempts to access a resource in the Engineering Realm. When the employee is properly 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, then maps the users identity to the authorization directory. Once this is done, the Policy Server can verify if the employee has access to the requested realm.

Temporary Employee Accesses a Quality Assurance Realm Resource

In the CA SiteMinder® protected network described in the previous figure, a temporary employee’s authentication data resides in the Temporary Employee Authentication user directory, and the employee attempts to access a resource in the Sales Realm. The Sales Realm is not associated with its own authorization directory. CA SiteMinder® authenticates the employee in the Temporary Employee Authentication directory, then checks to see if a directory mapping is set up. Since the Sales Realm does not have its own authorization directory, CA SiteMinder® attempts to authorize the employee using information in the same directory where the employee was authenticated.

Directory Mapping by Universal ID

In the CA SiteMinder® protected network described in the previous figure, an employee’s authentication data resides in the Central Authentication user directory, and the employee attempts to access a resource in the Engineering Realm. When the employee is properly authenticated, the Policy Server uses a directory mapping to find the employee in the Engineering Authorization directory, based on the employee’s Universal ID (see the following figure).

In the diagram above, assume the directory mapping uses a Universal ID. The Policy Server uses the attribute in the authentication directory that is defined as the universal ID to find a matching universal ID in the authorization directory. Once the universal ID is located in the authorization directory, the CA SiteMinder® can finish processing policies to determine whether or not the user can access a protected resource.

Directory Mapping Case Sensitivity

Case-sensitive directories, such as an Oracle database, treat the values "ROBIN" and "robin" as two different usernames. Other directories, such as an LDAP directory, are not case-sensitive and treat the values "Robin", "ROBIN", "robin", and "RobIn" as the same username. This can be a problem when a user is authenticated using a directory that is not case-sensitive, but authorized using a directory that is case-sensitive.

When authentication fails because the authentication directory is case-sensitive, the user can recover by reentering the username in the format required by the directory. If the directory requires the username to be in the format "Name", for example, the user can reenter the name correctly as "Robin". When authorization fails because the authorization directory is case-sensitive, however, the Policy Server has no way to recover.

When the authorization directory is case-sensitive, you can change the format of the authenticated username, so that it matches the format required by the authorization directory. If the authenticated username is "RoBiN", but the authorization directory requires the username to be in the format "Name", you can first change "RoBiN" to "Robin" and then authorize the user.

Identity Mapping by Complex User Search Criterion

Identity Mapping locates a user based on the session ticket information and how the identity mapping entries are constructed.

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);