Rules with a Web Agent action either allow or deny access to the resource(s) specified by a rule when one of the HTTP actions specified in the rule occur.
When a rule that specifies Allow Access fires, if a user authenticates successfully, SiteMinder allows the user to access the specified resource. If a rule specifies Deny Access, SiteMinder denies access to the successfully authenticated user. Deny access rules may be added to policies to provide an additional layer of security by rejecting specific individuals or groups who should not 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:
Retrieves a resource for viewing via HTTP.
Supports legacy HTTP actions.
Posts information supplied by a user via HTTP.
If you have purchased CA SOA Security Manager, two additional Web Agent rule actions are available for SOA Agent use:
Supports incoming XML messages wrapped with a SOAP envelope.
Supports incoming raw XML messages not wrapped with a SOAP envelope.
For more information, see the CA SOA Security Manager Policy Configuration Guide.
Affiliate Agents are SiteMinder Agents that communicate with SiteMinder Web Agents installed on the Web servers of a portal Web site.
Affiliate Agent rules are very simple, since they do not protect the resources of an affiliate Web site. The Affiliate Agent processes responses sent from the portal site, so that applications on the affiliate Web site may take advantage of the information gathered about users on the SiteMinder protected portal Web site.
Affiliate Agent actions are only available in the place of Web Agent actions for realms associated with an Affiliate Agent. There is only one possible action:
Allows a SiteMinder portal site to interact with an affiliate Web site
Note: For more information about Affiliate Agents, see the Web Agent Configuration Guide.
Authentication events occur as 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 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 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 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 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 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 © 2012 CA.
All rights reserved.
|
|