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 CA 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 CA 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 CA SiteMinder® Agent. For OnAuthReject rules, the Policy Server only returns the responses associated with the rule in the deepest nested realm to the CA 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.
Rules with a web agent action either allow or deny access to the resources specified by a rule when one of the HTTP actions specified in the rule occur.
When a rule that specifies Allow Access fires, CA SiteMinder® allows the user to access the specified resource upon authenticating successfully. If a rule specifies Deny Access, CA SiteMinder® denies access to the successfully authenticated user. Deny access rules can be added to policies to provide an additional layer of security by rejecting specific individuals or groups who cannot have access to a resource. Allow Access is the default.
Deny access rules take precedence over allow access rules. If a deny access rule and an allow access rule fire when a user attempts to access a resource, the presence of the deny access rule overrides all allow access rules.
The Web Agent rule actions are:
Two additional Web Agent rule actions are available for WSS Agent use:
Supports incoming XML messages wrapped with a SOAP envelope.
Supports incoming raw XML messages not wrapped with a SOAP envelope.
Authentication events occur as CA SiteMinder® tries to establish a user identity. As a rule action, an authentication event causes the Policy Server to fire a rule at a particular point in the authentication process.
Authentication events occur when a user accesses a resource protected by a rule that includes an On-Auth event. Unlike Web Agent actions or authorization events, authentication events always apply to the entire realm. You cannot create an On-Auth rule that applies to a portion of a realm.
The following is a list of possible authentication events:
Occurs if authentication was successful. This event can be used to redirect a user after a successful authentication.
Occurs only during the login stage. The user credentials are presented and generate the creation of a new session.
Occurs if authentication failed for a user that is bound to a policy containing an On-Auth-Reject rule. This event may be used to redirect the user after a failed authentication.
OnAuthAccept and OnAuthReject events fire both at authentication time (when the user enters their username and password) and at validation time (when the user cookie is read for user information). However, there are certain special actions that only occur at authentication time:
Unless your Web Agent supports the EnforceRealmTimeouts option and that option is enabled, the user Idle and Max Timeouts remain at the values for the realm in which the user last authenticated. The values only change if the user has to reenter their credentials.
Redirects are only allowed at authentication time to prevent the possibility of infinite redirect loops.
The password is not stored in the SMSESSION cookie, so the only time it is available is when the user actually enters it (authentication time).
Note: OnAuth event results are per realm. So for example, if a user goes from realm A to realm B and the user has an OnAuthAccept header in realm A, it is not available in realm B. When the user goes back to realm A, the header is set again.
Occurs if the user is rejected because CA SiteMinder® does not know this user. For example, an unregistered user can be redirected to register first.
Occurs when custom challenge-response authentication schemes are activated (for example, a token code).
This event is only used to trigger Active Responses. Do not use this event to trigger any response other than an Active Response.
A rule with an authentication event action may be coupled with a CA SiteMinder® response in a policy. When a user is authenticated (or rejected), the Policy Server passes any response that is associated with the applicable On-Auth rule back to the requesting Agent.
Note: You can optimize CA SiteMinder® performance and can limit the number of times the Web Agent must retrieve static information from the Policy Server. To optimize performance, set up a rule that is based on the OnAuthAccept authentication event and create a response that returns the static information. When you bind the rule and response in a policy, the rule fires for users specified in the policy. The static response is only returned to users who successfully authenticate.
Authorization events occur as CA SiteMinder® verifies whether or not a user is authorized to access a resource. As a rule action, an authorization event causes the Policy Server to fire a rule at a particular point in the authorization process.
The following is a list of possible authorization events:
Occurs as the result of successful authorization. This event may be used to redirect users who are authorized to access a resource.
Occurs as the result of failed authorization. This event may be used to redirect users who are not authorized to access a resource.
A rule with an authorization event action may be coupled with a CA SiteMinder® response in a policy. When a user is authorized (or rejected), the Policy Server passes any responses associated with the applicable On-Access rule back to the requesting Agent.
Impersonation provides a method for a privileged user to assume the role of another user without ending the privileged user’s session. Impersonation events are used to start impersonation sessions when resources are accessed.
Possible impersonation events:
When included in an appropriate policy, a rule that includes this event allows an impersonation session to begin.
When included in an appropriate policy, a rule that includes this event allows a set of users to be impersonated.
Advanced options allow you to define additional rule settings:
Specify when a rule should and should not fire.
Allow dynamic authorization based on external business logic.
|
Copyright © 2014 CA.
All rights reserved.
|
|