Policies

Policies define how users interact with resources.
To create a policy in the Administrative UI, you link together (bind) objects that identify the following properties:
  • Users
  • Resources
  • Actions that are associated with the resources
Policies are stored in policy domains. When you configure a policy, you can select users and groups from the user directories available in the policy domain.

The Policy Server identifies resources through rules. When you create a policy, you can select rules that specify the resources you want to include in a policy.Once you identify users and resources in a policy, you can specify actions to take place when those users access the specified resources. These actions take the form of responses. Policies can include responses that do the following things:
  • Allow or deny access to a resource
  • Customize user session time
  • Redirect the user to other resources
  • Customize the content that the user receives based on attributes that are contained in a user directory.\
More advanced policies can be restricted to certain time periods or certain user IP addresses. This allows administrators of a group of resources a finer control over their resources.The following diagram illustrates all of the possible parts of a policy. 
policy-overview.png
  • Rules/Rule Groups
     A policy must contain at least one rule or rule group. A rule identifies a specific resource or resources that are included in the policy.
  • Users
     A policy must specify the users or groups of users that are affected by the policy. Connections to these users or groups of users must be configured on the User Directory screen. Only users or user groups for directories that are included in the policy domain in which the policy is located may be associated with a policy.
  • Responses
     A response defines the action that is triggered when a user accesses a resource specified in a rule. Responses can return attributes from a user directory for use by other applications or to customize content. Responses can also trigger actions based on authentication and authorization events.
  • (Optional) IP Addresses
     A policy may be limited to specific user IP addresses. Once you add an IP address restriction to a policy, if a user attempts to access a resource from an IP address that is not specified in the policy, the policy will not fire for the user, and therefore will not allow/deny access or process any responses.
  • (Optional) Time Restrictions
     A policy may be limited to specific days or ranges of hours. A policy with a time restriction will not fire outside specified times, and therefore will not allow/deny access to protected resources or process any responses.
  • (Optional) Active Policies
     An Active policy allows business logic external to CA Single Sign-On to be included in a policy definition. Active policies allow CA Single Sign-On to interact with custom software created using the CA Single Sign-On APIs.
Policy Bindings
A policy binding is the method used to link a user with a policy. The Policy Server only resolves policies for users who are part of a policy binding created by the users or groups contained in a policy.
Before the Policy Server can resolve a user’s attempt to access a protected resource, the user must be authenticated. When CA Single Sign-On authenticates a user, it establishes a context for the user. The user context provides information about who the user is and what privileges the user has when accessing resources.
For example, if a user is part of the group in a user directory called Employees, when the user authenticates, the Policy Server creates a policy binding for the user’s membership in the group Employees. When the user attempts to access a resource protected by a rule in a policy that allows access for Employees group members, the user’s policy binding allows CA Single Sign-On to authorize the user.
Expressions in Policies
eTelligent Rules makes available a set of variables for use in policy expressions.
Expressions extend policies to include dynamic information evaluated at runtime. Variable objects may be used in expressions to create a boolean set of conditions that determines entitlements for the resources protected by the policy.
To use variable objects in an active policy expression, you must configure a policy object and build the appropriate boolean expression using the Expression dialog. The interface is similar to the LDAP Search Expression editor described in Add LDAP Expressions to Policies.
Note:
 Expressions may be added to other data supported by policy objects as shown in the following figure:
variable-expression.png
Note:
 Active expressions and named expressions are not the same. While both types of expressions are evaluated at run-time, they differ in the following ways:
  • While active expressions are Boolean expressions, named expressions can return a string, number, or Boolean value.
  • While active expressions are referenced as is and must be reentered each time that they are used, named expressions are referenced by name and can be referenced from anywhere and reused.
Confidence Levels in Policies
If CA Single Sign-On is integrated with a supported risk analysis engine, a confidence level is available for use in policies. Confidence levels extend policies to include the results of the risk evaluation that is completed as part of user authentication. The Policy Server can use these results when making authorization decisions.
You can apply a confidence level to the following objects:
  • A policy realm: A confidence level that you configure in a realm applies to all resources (rules) that are associated with the realm. Applying a confidence level to a policy realm requires that you enable confidence level support.
  • An active policy expression: A confidence level that you configure as an active policy expression applies only to those resources (rules) that are bound to the policy. The active policy expression allows for more granular authorization decisions. Using an active policy expression to apply a confidence level remains supported from previous releases and is enabled by default.
Note:
 CA Single Sign-On supports an integration with an on–premise implementation of CA Arcot WebFort and CA Arcot Risk, and a hosted implementation of CA Arcot A–OK.