This section contains the following topics:
Configure a Rule for Web Agent Actions
Configure a Rule for Authentication Event Actions
Configure a Rule for Authorization Event Actions
Configure a Rule for Impersonation Event Actions
Resource Matching and Regular Expressions
Rules identify specific resources and either allow or deny access to the resources. Rules can also be used to trigger responses when authentication or authorization events take place. When you create rules, you must associate rules with specific realms.
The following diagram illustrates a number of realms and nested realms and their associated rules.
In the diagram above, different realms and nested realms have specific rules associated with the resources in the realm. It is also possible to have a single rule associated with all of the resources in a realm, or a subset of resources in the realm. This is done by using resource matching or regular expressions to specify resources.
Policies protect resources by binding together rules, users, and responses. Rules are the parts of policies that determine precisely which resources are protected, and which types of actions cause a rule to fire.
For example, a rule can specify all HTML files in a realm are protected for a GET action, which a Web server uses to respond to a request for an HTML page. When a user’s browser attempts to access the resource, the rule fires and the policy containing the rule determines whether or not the user can view the selected resource.
The Policy Server evaluates rules according to the relationships between users, rules, and responses defined in policies. When a user accesses a protected resource, the Policy Server must process rules included in policies to determine whether or not the user is authorized for the resource, if any authentication and authorization events must be processed, and if any responses should be generated and returned to SiteMinder Agents.
When the Policy Server processes an authorization event, it looks for the realm with the longest resource filter matching the protected resource. Then, the Policy Server fires only those rules associated with that realm. In this example, the user is a manager, who wants to access the following protected resource:
/company/employees/managers/performance/
The following realms have resource filters that match the protected resource:
|
Realm Name |
Realm Description |
Resource Filter |
|
Company |
Customers, employees, vendors |
/company/ |
|
Company Employees |
All employees |
/company/employees/ |
|
Company Managers |
All managers |
/company/employees/managers/ |
|
Performance Management |
Managers with team members |
/company/employees/managers/performance/ |
The realm with the longest matching resource filter is Performance Management. In response to the authorization event, the Policy Server fires all rules associated with the Performance Management realm.
In a deployment of nested realms, the Policy Server keeps a ranked list of matching realms for use during processing. If any matching rules deny access to a resource, processing stops, and the Policy Server returns any responses associated with the deny access rule to the SiteMinder Agent.
The Policy Server collects responses from all matching rules that fire. When the Policy Server finishes collecting responses based on rules, it deletes any duplicate responses.
In a deployment that uses nested realms, the Policy Server collects the entire list of accumulated responses for all matching rules. For OnAuthAccept rules, the Policy Server returns the entire list of responses to the SiteMinder Agent. For OnAuthReject rules, the Policy Server only returns the responses associated with the rule in the deepest nested realm to the SiteMinder Agent. OnAuthReject rules fire only for users bound to the policy.
Nested realms are realms created within an existing realm. A nested realm has a parent, or top level realm, and is considered a child of the parent realm. When you create nested realms, you can also create separate rules to protect the resources in the child realms. You may also copy an existing rule, attach the rule to another realm, and rename the rule.
A rule’s action determines what must take place for the rule to fire. A rule fires when the Policy Server determines that an action specified in a rule occurs. The rule must be contained in an existing, enabled policy. For example, if a policy contains a rule that allows access to an HTML page, and the policy specifies users who exist in a particular directory, when one of the users listed in the directory attempts to access a resource, the Policy Server determines that the rule must fire in order to process the request.
When a rule fires, the Policy Server processes the action specified in the rule based on the way the policy that contains the rule is configured. For example, if a user is not in a group specified in a policy, a rule that allows an HTTP Get action for an HTML page will not allow the user to access the resource.
|
Copyright © 2012 CA.
All rights reserved.
|
|