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 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.
You can create a rule that fires in response to specified Web Agent actions and that allows or denies access to the resource that the rule is designed to protect.
Note: You can also create a rule for the CA SOA Security Manager XML Agent. When creating a rule for this Agent type, two additional rule actions are available: ProcessSOAP and ProcessXML. For more information, see the CA SOA Security Manager Policy Configuration Guide.
To create a rule
The Rules page appears.
The Create Rule: Select Domain page appears.
The Create Rule: Select Realm page appears.
The Create Rule: Define Rule page appears.
Note: If a realm does not exist for the resources that you want to protect, a rule cannot be created to protect those resources.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
The Effective Resource updates to include the resource.
The Action List is populated with HTTP actions.
The Rule for Web Agent actions is created.
You can configure a rule for authentication event actions to control actions that occur when users authenticate to gain access to a resource.
The realm in which the rule is to be created must be able to process authentication events. Verify that the Process Authentication Events option is selected.
To create a rule
The Rules page appears.
The Create Rule: Select Domain page appears.
The Create Rule: Select Realm page appears.
The Create Rule: Define Rule page appears.
Note: If a realm does not exist for the resources that you want to protect, a rule cannot be created to protect those resources.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
The Action List populates with authentication events.
Note: The Resource field is disabled because an authentication event applies to the entire realm. The Allow Access and Deny Access options are also disabled as they do not apply to authentication events.
The rule is saved and applied to the specified realm and resource.
Authorization events occur after a user is authenticated. You configure a rule for authorization to let CA SiteMinder® call responses based on whether a user is or is not authorized for the requested resource. When the user has been granted or denied access based on their privileges, the appropriate event is triggered.
The realm in which the rule is to be created must be able to process authorization events. Verify that the Process Authorization Events option is selected.
To create a rule
The Rules page appears.
The Create Rule: Select Domain page appears.
The Create Rule: Select Realm page appears.
The Create Rule: Define Rule page appears.
Note: If a realm does not exist for the resources that you want to protect, a rule cannot be created to protect those resources.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
Effective Resource updates to include the resource.
The Action List populates with authorization events.
Note: The Allow Access and Deny Access options are disabled. These options do not apply to authorization events.
The rule is saved and applied to the specified realm and resource.
Consider how the Policy Server processes global policies and the special circumstances created by OnAccessReject rules when creating global rules that include OnAccessReject events.
An OnAccessReject rule will not fire if it is in the same policy as a GET / POST rule. When a user is authenticated, CA SiteMinder® resolves the identity of the user. Therefore, if the OnAccessReject rule and the GET / POST rule are in the same policy, then a user who is allowed access to a resource is the same user who should be redirected on an OnAccessReject event. Since the user is allowed access, the reject event never applies.
To resolve this discrepancy, create a separate policy for the OnAccessReject rule, which may include other event rules, and specify the users for which it should apply.
For example, in an LDAP user directory, User1 should have access to a resource and everyone else in the group, ou=People, o=company.com, should be redirected to an OnAccessReject page. Two policies are required:
Includes a GET / POST rule that allows access for User1.
Includes the OnAccessReject rule and a Redirect response, and specifies the group ou=People, o=company.com.
Since User1 is authorized, the OnAccessReject rule will not fire when User1 access the resource. However, the OnAccessReject rule will fire for all other users in the group, ou=People, o=company.com, because they are not authorized to access the resource.
You can configure a rule for impersonation events to start impersonation sessions when resources are accessed.
To create a rule
The Rules page appears.
The Create Rule: Select Domain page appears.
The Create Rule: Select Realm page appears.
The Create Rule: Define Rule page appears.
Note: If a realm does not exist for the resources that you want to protect, a rule cannot be created to protect those resources.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
The Effective Resource updates to include the resource.
The Action List populates with impersonation events.
Note: The Allow Access and Deny Access options are disabled. These options do not apply to impersonation events.
The rule is saved and applied to the specified realm and resource.
Rules may use resource matching and regular expression matching to specify resources in a realm.
By default, resource matching for a rule is done with wildcards.
The following table describes the characters that are supported for resource matching.
|
Character |
Use |
|---|---|
|
* |
The wildcard (*) is used to match all characters in the string. The expression *.html will match all files with a .html file extension, such as index.html, out.html, and so forth. |
|
? |
The question mark (?) will match a single character of the string. The expression lmn?p will match the sub-string lmnop, lmnep, and so forth. |
Regular expressions allow for greater flexibility in resource matching. To enable regular expression matching, in the CA SiteMinder® Rule dialog, select the Regular Expression check box.
Regular expressions are text patterns used for string matching. Examples of the syntax used in regular expressions are shown in the following table:
|
Characters |
Results |
|---|---|
|
\ |
Used to quote a meta-character (like ’*’) |
|
\\ |
Matches a single ’\’ character |
|
(A) |
Groups subexpressions (affects order of pattern evaluation) |
|
[abc] |
Simple character class (any character within brackets matches the target character) |
|
[a-zA-Z] |
Character class with ranges (any character range within the brackets matches the target character) |
|
[^abc] |
Negated character class |
|
. |
Matches any character other than newline |
|
^ |
Matches only at the beginning of a line |
|
$ |
Matches only at the end of a line |
|
A* |
Matches A 0 or more times (greedy) |
|
A+ |
Matches A 1 or more times (greedy) |
|
A? |
Matches A 1 or 0 times (greedy) |
|
A{n} |
Matches A exactly n times (greedy) |
|
A{n,} |
Matches A at least n times (greedy) |
|
A{n,m} |
Matches A at least n but not more than m times (greedy) |
|
A*? |
Matches A 0 or more times (reluctant) |
|
A+? |
Matches A 1 or more times (reluctant) |
|
A?? |
Matches A 0 or 1 times (reluctant) |
|
AB |
Matches A followed by B |
|
A|B |
Matches either A or B |
|
\1 |
Backreference to 1st parenthesized subexpression |
|
\n |
Backreference to nth parenthesized subexpression |
Limit: Each regular expression can contain no more than 10 subexpressions, including the expression itself. The number of subexpressions equals the number of left or opening parentheses in the regular expression plus one more left parenthesis for the expression itself.
You enable a rule to ensure CA SiteMinder® protects the specified resources. You disable a rule to prevent CA SiteMinder® from protecting the specified resources.
If a rule is enabled, no one may access the protected resource(s) unless a policy that contains the rule has been created, and the user attempting to access the rule is part of a group specified in the policy. To allow access to resources before a policy is put into place, you can disable the rule.
To enable or disable a rule
The rule is saved.
The Advanced group box on the Rule pane is where you define additional rule settings. This group box lets you set time restrictions and active rules. Time restrictions and active rules are discussed in the following sections.
You configure time restrictions to specify when SiteMinder should fire the rule.
Configuring a time restriction from 9am - 5 pm, Monday - Friday, for example, specifies that SiteMinder should only fire the rule during the specified time. Users have access to the resource when the rule is set to fire. The resource is not available outside of the specified time.
Note: More information about how SiteMinder handles time across multiple time zones exists in How the Web Agent and Policy Server Calculate Time.
To configure a time restriction
The Time Restrictions pane appears.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
Note: Each check box represents one hour. When a check box is selected, the rule fires during that hour, and the rule applies to the specified resources. When a check box is cleared, the rule does not fire during that hour, and the rule will not apply to the specified resources.
The time restrictions are saved, and the rule settings appear.
You configure an active rule for dynamic authorization based on external business logic. The Policy Server invokes a function in a customer-supplied shared library. This shared library must conform to the interface specified by the Authorization API, which is available in the Software Development Kit.
Note: For more information about shared libraries, see the Programming Guide for C.
To configure an Active Rule
The active rule string is displayed in the Active Rule field.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
The active rule is saved.
If you delete a rule, the rule is automatically removed from the policies that included the rule. However, the policies remain on your system. Verify that the policies function without the deleted rule.
Note: Policies must contain at least one rule.
When you delete a rule that is included in a rule group, it may take several seconds before the deleted rule is removed from the rule group. It may also take a short amount of time for all deleted objects to be removed from caches.
Note: More information about modifying and deleting Policy Server objects exists in Manage Policy Server Objects.
|
Copyright © 2013 CA.
All rights reserved.
|
|