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.
Global rules are the part of a global policy that define a resource and events that trigger the processing of a global policy. Global rules are similar to domain-specific rules. However, a global rule must be associated with an authentication or authorization event. There are no global allow/deny access rules.
Global rules that include CA SiteMinder® authentication events let you control actions that occur 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 authentication was successful. This event may be used to redirect a user after a successful authentication.
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 his / her username and password) and at validation time (when the user's cookie is read for user information). 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).
Note: More information on EnforceRealmTimeouts exists in section 3.3 of the SiteMinder 4.x Web and Affiliate Agent Quarterly Maintenance Release 4 Release Notes.
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 if the user was rejected because CA SiteMinder® 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 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.
To create a global rule
The Global Rules page appears.
The Create Global Rule page appears.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
Note: If you specify an Agent Group and have also configured domain-specific rules associated with the same resource, you may adversely affect system performance by effectively duplicating processing steps. Consider domain-specific rules that may duplicate the responses generated by global rules. In such cases, 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.
To create a global rule
The Global Rules page appears.
The Create Global Rule page appears.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
Note: If you specify an Agent Group and have also configured domain-specific rules associated with the same resource, you may adversely affect system performance by effectively duplicating processing steps. Consider domain-specific rules that may duplicate the responses generated by global rules. In such cases, 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.
You enable a global rule to ensure CA SiteMinder® fires the rule if a user accesses the specified resource and triggers the authentication or authorization event. You disable a global rule to prevent CA SiteMinder® from firing the rule if a user accesses the specified resource and triggers the authentication or authorization event.
To enable or disable a global rule
The rule is saved.
You add time restrictions to a global policy to ensure that the global policy only fires at specific times. If a user attempts to access a resource outside of the period specified by the time restriction, the policy does not fire.
To add a time restriction to a global rule
The Time Restrictions pane opens.
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.
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 global rule, the rule is automatically removed from any global policies that include the global rule. The global policies remain on your system. Verify that the global policies function without the deleted rule.
Global policies must contain at least one global rule.
Note: More information about modifying and deleting Policy Server objects exists in Manage Policy Server Objects.
Global responses are the part of a global policy that define the attributes to be returned after a user triggers the authentication or authorization event specified in a global rule.
Note: You may 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 policies, the global response will be 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.
To configure a global response
The Global Responses page appears.
The Create Global Response page appears.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
The global response is saved. You can now add response attributes to the response. For more information about adding response attributes for each Agent type, see Response Attributes for Global Responses.
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.
To create a response attribute
The Create Response Attribute page appears.
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.
To create a global policy
The Global Policies page appears.
The Create Global Policy page appears.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
The global policy is created.
Global rules indicate the specific resources included in a global policy. You must add at least one global rule to a global policy.
To add global rules to a global policy
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 you create in this manner are added to the global policy.
The Rules group box lists the selected rules and rule groups.
Global responses indicate the actions that should take place when the rule fires. When the rule fires, the associated response also fires.
To associate a response with a global rule
The Available Responses pane opens and lists the available responses, response groups, and global responses.
The response opens in the Rules group box, and is associated with the respective rule.
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. When a global policy is enabled, global rules contained in the global policy fire when users attempt to access the resources specified in the global rules.
If you disable a global policy, the rules contained in the policy do not fire.
To enable or disable a policy
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.
To configure an Active Policy
Active policy settings appear.
The policy is saved.
|
Copyright © 2013 CA.
All rights reserved.
|
|