A global policy is comprised of global rule objects and global response objects, including response attributes. The following process lists the procedures for creating a global policy:
Important! You can configure both global policies and domain-specific policies that affect the same resources. For example, you can configure domain-specific policies for access control, and global policies that provide a standard set of responses. However, in order for global policies to function, the realms included in the domain-specific policies must be configured to allow event processing.
The global rules are the part of a global policy that defines a resource and events that trigger the processing of a global policy. These global rules are similar to domain-specific rules. A global rule must be associated with an authentication or authorization event. No global allow/deny access rules are allowed.
Global rules that include authentication events let you control what occurs when users authenticate to gain access to a resource (On-Auth event).
Note: OnAuth event results are per realm, so for example, if a user goes from realm A to realm B and had an OnAuthAccept header in realm A, it will not be available in realm B. When the user goes back to realm A, the header will be set again.
The following is a list of possible On-Auth events:
Occurs if an authentication was successful. This event can be used to redirect a user after a successful authentication.
Occurs if an authentication failed for a user that is bound to a policy containing an On-Auth-Reject rule. This event can be used to redirect the user after a failed authentication.
OnAuthAccept and OnAuthReject events fire both at authentication time (when the user enters a username and password) and at validation time (when the cookie of the user is read). However, there are certain special actions that only occur at authentication time:
Unless you have a version of the Web Agent that supports the EnforceRealmTimeouts option and that option is enabled, the Idle and Max Timeouts for the user will stay at the values for the realm in which the user last authenticated (only changes if the user has to reenter credentials).
Redirects are only allowed at authentication time for a number of reasons, but one of the most practical is that it would be very easy to configure an infinite loop of redirection if OnAuth redirection were allowed at validation time as well.
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).
Occurs when the user was rejected since the product does not know this user (an unregistered user, for example, can be redirected to register first).
Occurs when custom challenge-response authentication schemes are activated (for example, a token code).
When a user is authenticated (or rejected), the Policy Server passes any global responses that are associated with the applicable On-Auth rule back to the requesting Agent.
Create a Global Rule for Authentication Events
You can create a global rule for authentication events to control actions that occur when users authenticate to gain access to a resource.
Follow these steps:
Note: If you specify an Agent Group with domain-specific rules that are associated with the same resource, you can adversely affect system performance. Consider domain-specific rules that duplicate the responses that are generated by global rules. Only one response is returned to the Agent because the Policy Server automatically deletes duplicate responses before passing information back to the requesting Agent.
The global rule is saved.
Global rules that include CA SiteMinder® authorization events allow CA SiteMinder® to call responses based on whether a user is or is not authorized for the resource the user requested. Authorization events occur after a user is authenticated, if a rule that protects a resource contains an On-Access event. When the user has been granted or denied access based on their privileges, the appropriate event is triggered.
The following is a list of possible On-Access 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.
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.
Policy Considerations for OnAccessReject Rules
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.
Create a Global Rule for Authorization Events
You create a global rule for authorization events to control actions that occur when users authenticate to gain access to a resource.
Follow these steps:
Note: If you specify an Agent Group with domain-specific rules that are associated with the same resource, you can adversely affect system performance. Consider domain-specific rules that duplicate the responses that are generated by global rules. Only one response is returned to the Agent because the Policy Server automatically deletes duplicate responses before passing information back to the requesting Agent.
You enable a global rule to ensure the rule fires when a user accesses the specified resource. Disable a global rule prevent the rule from firing the rule when a user accesses the specified resource.
Follow these steps:
The rule is saved.
Add time restrictions to a global policy enforce it at specific times. When a user attempts to access a resource outside of the specified time period, the policy is not enforced.
Follow these steps:
Note: Each check box represents one hour. Selecting a check box fires the rule during that hour. The rule applies to the specified resources. Clearing a check box means that the rule does not fire during that hour. The rule does not apply to the specified resources.
You configure an active rule for dynamic authorization that is 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.
Follow these steps:
The active rule string is displayed in the Active Rule field.
The active rule is saved.
Deleting global rules automatically removes the rule from any global policies that use it. The global policies remain on your system. Verify that the global policies function without the deleted rule.
All global policies must contain at least one global rule.
The global responses are parts of global policies that define the attributes to be returned to a user. These attributes are returned after a user triggers the authentication or authorization event that is specified in a global rule.
Note: You can use global responses in domain policies. In order to be returned, a global response must be added to a domain-specific or global policy. Within the policies, the global response is processed like a domain-specific response.
You can configure a global response to define the attributes that are returned after the authentication or authorization event occurs in an associated global rule.
Follow these steps:
The global response is saved. You can now add response attributes to the response.
Each CA SiteMinder® global response may contain one or more response attributes. Response attributes identify the pieces of information that the Policy Server passes to a CA SiteMinder® Agent. Each CA SiteMinder® Agent type can accept different response attributes.
CA SiteMinder® supports different types of response attributes. The types of response attributes determine where the Policy Server finds the proper values for the response attributes. The types of response attributes that you can configure for a global response are identical to the types of response attributes you can configure for a domain-specific response.
You can configure a response attribute to store the pieces of information that the Policy Server passes to a CA SiteMinder® Agent. Web Agent response attributes support HTTP header variables, cookie variables, redirections to other resources, text, and timeout values. More information on Web Agent response attribute types exists in the Web Agent Configuration Guide.
Note: If you have purchased CA SOA Security Manager, you can find information about the WebAgent-SAML-Session-Ticket-Variable response attribute type in the CA SOA Security Manager Policy Configuration Guide.
Follow these steps:
The details in the Attribute Fields are updated to match the specified attribute type.
Note: A list of automatically generated CA SiteMinder® user attributes that you can use in responses exists in SiteMinder Generated User Attributes.
Note: The Attribute Setup section closes when you edit the attribute on the Advanced section.
Note: The maximum time limit that can be entered is 3600 seconds.
The Create Response Attribute Task is submitted for processing, and the response attribute is added to the Attribute List on the Response page.
Configuring a global policy requires you to complete the following procedures:
You can create a global policy to define how users interact with resources.
Follow these steps:
The global rules indicate the specific resources that are included in a global policy. Add at least one global rule to a global policy.
Follow these steps:
The Rules group box opens.
The Available Rules pane opens and lists the available global rules.
Note: If the global rule you require does not appear, click New Rule. Rules that you create in this manner are added to the global policy.
The Rules group box lists the selected rules and rule groups.
The global responses indicate the actions that occur when the rule fires. When the rule fires, the associated response also fires.
Follow these steps:
Note: If the response you require does not exist, click New Response to create the response.
The Administrative UI allows you to enable and disable global policies. By default, when you create a global policy, the policy is enabled. Any Global rules that are contained in the global policy fire when users attempt to access the resources that are specified in those rules.
If you disable a global policy, the rules that are contained in the policy do not fire.
Follow these steps:
If the check box is selected, the policy is enabled. If the check box is cleared, the policy is disabled. A disabled policy does not fire.
The policy is saved.
An active policy is used for dynamic authorization based on external business logic. An active policy is included in the authorization decision by having the Policy Server invoke a function in a customer-supplied shared library.
This shared library must conform to the interface specified by the Authorization API (available separately with the Software Development Kit.
Note: More information exists in API Reference Guide for C.
The process for configuring active policies for global policies is identical to the process for configuring active policies for domain-specific policies.
Follow these steps:
Active policy settings appear.
The policy is saved.
|
Copyright © 2014 CA.
All rights reserved.
|
|