Multiple directory mappings may be needed in order to correctly authenticate and authorize users that have access to network resources. The following figure illustrates a simple sample case where multiple directory mappings may be 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. The Policy Server uses one of the authentication directories based on where the user’s information is stored and one of the authorization directories if the requested resource is in the Marketing, Engineering, or Quality Assurance realms.
In the 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.
In the 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. 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, SiteMinder attempts to authorize the employee using information in the same directory where the employee was authenticated.
In the 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 SiteMinder can finish processing policies to determine whether or not the user can access a protected resource.
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.
|
Copyright © 2012 CA.
All rights reserved.
|
|