The Policy Server use policies to authorize access to resources and provide entitlements to authorized users. The resources protected by policies are usually stored in a hierarchy that mimics security, organizational, and business requirements and takes advantage of the SiteMinder’s hierarchical or “nested” realms. The remainder of this chapter discusses how SiteMinder processes policies and gathers entitlements in a hierarchical structure.
This section explains the sample configuration that will be used in examples in the remainder of this chapter.
Assume that the policy domain that contains the policies and other relevant Policy Server objects includes a connection to the LDAP user directory in the following diagram.
The sample user directory contains the following:
This is an organization.
This is an organizational unit that contains information for all employees.
These are directory entries for each employee. Note that a_lvl is a user attribute that indicates an access level. For the purpose of the examples in this section, assume that employee1 and employee2 have an access level of zero (a_lvl=0).
This is a group that contains all company employees as its members.
This is a group that contains all employees with a managerial title as its members. Note that employee3 and employee4 are the only employees in this group, and their respective access levels are greater than zero.
The structure of nested realms and resources used in the examples in this section are illustrated in the following diagram. The shaded areas indicate realms that are protected by an authentication scheme.
The nested realms are made up of the following directories and resources:
This directory is the top level of the sample nested realm. This realm specifies /home/ as its resource filter, and contains the unprotected resource of index.html. The index.html file is not protected by an authentication scheme.
This directory, contained in the /home directory, is protected by a Basic authentication scheme, which requires a user name and password as credentials. The realm associated with this directory uses a resource filter of employees/ and contains the employee.html file. The total Resource Filter for this realm is
/home/employees/.
This directory, contained in the /employees directory, is protected by an HTML Forms authentication scheme which requires a user name, password, and additional personal information as credentials. The realm associated with this directory uses a resource filter of managers/ and contains the manager.html file. The total Resource Filter for this realm is /home/employees/managers/.
This directory, contained in the /managers directory, is protected by an X.509 Certificate + Basic authentication scheme which requires user name, password, and a valid X509 certificate as credentials. The realm associated with this directory uses a resource filter of restricted/ and contains the restricted.html file. The total Resource Filter for this realm is /home/employees/managers/restricted/.
In these examples the protection level of the /employees realm is less than the protection level of the /managers realm, which is less than the protection level of the /restricted realm.
The policies and responses used in the examples in the remainder of the chapter are illustrated in the following diagram and described below.
The following is a description of each of the sample policies and the objects contained in each policy.
This policy contains a Get rule that protects the employee.html resource. This resource is located in the /employees realm. The policy binds the user group cn=employees, so that all employees in the LDAP directory can access the resource once they are successfully authenticated. When an authenticated user is authorized by this policy, SiteMinder returns a response of the user’s email address. For example, if employee1 attempts to access
/home/employees/employee.html and is successfully authenticated, the Policy Server allows employee1 to access the resource and returns the email address:
employee1@myorg.org
A Web application can use this response for customization when accessing other company resources.
This policy contains a Get rule that protects the manager.html resource. This resource is located in the /manager realm. The policy binds the user group cn=managers so that only employees contained in cn=managers group can access the resource once they are successfully authenticated. When an authenticated manager is authorized by this policy, SiteMinder returns a static response. In the example, if employee3 attempts to access /home/employees/managers/manager.html and is successfully authenticated, the Policy Server allows employee3 to access the resource and returns the following response:
manager=YES
An application can use this response to activate features that are only available to company managers.
This policy contains a Get rule that protects the restricted.html resource. This resource is located in the
/restricted realm. The policy binds only the employees in the directory who have an access level user attribute of two (a_lvl=2). Managers with the correct access level can access the resource once they are successfully authenticated. When a user attempts to access the restricted.html resource, SiteMinder returns a response of a_lvl=<0-2>. For example, if employee4 attempts to access
/home/employees/managers/restricted/restricted.html and is successfully authenticated, the Policy Server allows employee4 to access the resource and returns the following response:
a_lvl=2
An application can use this response to activate features that are only available employees with an access level of two.
Policies must contain rules. Rules can include authentication and authorization events. Based on how rules are configured, one of four authentication events can occur when the Policy Server attempts to identify a user based on credentials.
The authentication is successful.
The authentication fails because the user is not found in any directory in the policy domain’s search order.
The user is found in a directory, but the authentication fails because the credentials supplied by the user are incorrect. If this occurs, the Policy Server looks in the next directory in policy domain’s directory search order. If the user’s credentials cannot be verified in any of the directories in the search order, the Policy Server processes OnAuthReject events.
The user must be found in a directory for an OnAuthReject rule to fire. If the user is not found in any directory, an OnAuthReject rule will not fire.
The authentication server has a valid session ticket, yet it cannot find the user directory. This situation should only occur in a single sign-on environment that uses multiple directories, though it may take place if a user was idle long enough to be removed from the Agent’s cache, and the user was removed from the directory. When this event occurs, the Policy Server evaluates the user’s existence in the directory rather than relying on the session ticket.
The Policy Server attempts to authenticate users based on the longest matching realm. For example, if a user attempts to access /home/employees/managers/manager.html, the Policy Server uses the /managers realms to determine the required credentials. In the example in the previous figure, the user must complete a browser-based form required by the HTML Forms authentication scheme associated with the realm.
Note: The longest matching realm also determines the timeouts for the user’s session. If a timeout is associated with the realm in which the user successfully authenticated, that timeout is used. You can use responses to override a realm timeout for a specific resource or group of resources.
OnAuthAccept rules fire when all of the following are satisfied:
At this point, the Policy Server collects OnAuthAccept entitlements from the longest matching realm, and any realms above it in the hierarchy of nested realms. In the example in the previous figure, if a user is successfully authenticated for the resource /home/employees/managers/manager.html, the Policy Server collects any OnAuthAccept entitlements for the /managers realm, then the /employees realm, and finally the /home realm.
Policy domains are configured with a directory search order. When the Policy Server attempts to authenticate a user, it searches each user directory in the search order until it finds the user and verifies the supplied credentials. If the Policy Server locates a user in a directory, but the credentials supplied by the user do not match, the Policy Server looks at the next directory in the search order. If the Policy Server does not find a match for the user in any directory, the user’s authentication attempt fails in the context of the realm that contains the requested resource.
For example, if a user attempts to access
/home/employees/managers/manager.html, and the user is located in a user directory, but fails to provide valid credentials for any directory in the search order, the authentication event fails in the /managers realm. The Policy Server then processes any events for a rejected authentication attempt in that realm (OnAuthReject).
If the Policy Server cannot find the user who attempts to authenticate in any of the directories in the directory search order, the authentication fails in the context of the realm that contains the requested resource. The Policy Server then processes any events for a failed authentication attempt (OnAuthAttempt).
Policies can contain rules that allow access to resources and may also include rules that trigger SiteMinder events. The possible authorization events include the following:
This type of event occurs when a user is successfully authorized.
This type of event occurs when an authenticated user is denied access to a resource.
If a rule does not specify an authorization event, the rule either allows or denies access to the resource.
For the Policy Server to authorize a user to access a resource in a nested realm, the user must be authorized in each realm from the top of the hierarchy to the realm that contains the resource. Once a user is authenticated, the Policy Server checks the policies governing each realm above the resource to make sure the user is authorized. In the previous example, if employee3 wants to access /home/employees/managers/manager.html, the Policy Server verifies that employee3 is authorized in /home, /employees, and finally, /managers.
Once the Policy Server determines that the user is authorized, it collects entitlements for the user from each of the nested realms. Next, the Policy Server processes OnAccessAccept events starting at the top of the realm hierarchy and moving through the longest matching realm. In the previous example, the responses returned by the Policy Server would include employee3’s email address, as well as the static response manager=YES.
Policy processing for unauthorized users is the same, whether or not the user is explicitly denied access by a policy, or simply not contained in a policy that allows access. Any entitlements collected so far for that user are lost and the Policy Server processes OnAccessReject events in the context of the rejecting realm where the requested resource is located.
In the previous example, if employee1, who is not a member of the cn=managers group, attempts to access /home/employees/managers/manager.html, the Policy Server only processes OnAccessReject events for the /managers realm.
In a SiteMinder configuration that contains nested realms, each realm may contain a directory mapping which specifies an authorization directory to be used which is different from the authentication directory. This allows companies to use a single directory for authenticating users, while distributing authorization directories throughout an enterprise. When the Policy Server processes entitlements in a group of nested realms, the it checks for directory mappings for each realm in the hierarchy. If there is no directory mapping, the Policy Server uses the authentication directory as the authorization directory.
|
Copyright © 2012 CA.
All rights reserved.
|
|