The Policy Server resolves variable objects to a value which you can incorporate into the authorization phase of a request. The value of a variable object is the result of dynamic data and is evaluated at runtime. Variables provide a flexible tool for expanding the capabilities of policies and responses.
The following types of variables are available:
Static variables consist of a simple name/value pair of a particular type, such as string, boolean, and others. The key benefit of a static variable is to implement good programming practices. Instead of repeating the value of a constant each time it’s used in a policy, a static variable provides a single piece of data that can be used throughout multiple policies.
Each request that is processed establishes a request context. This context identifies the following properties:
Indicates the type of action that is specified in the request, such as GET or POST.
Indicates the requested resource, such as /directory_name/.
Indicates the full server name that is specified in the request, such as server.example.com.
A request context variable can capture any of this information and can make it available for inclusion in a policy expression or response. The key benefit of this type of variable is to provide fine-grained request context information without any programming logic.
When the Policy Server authenticates a user against an entry in a directory, a user context is created. The user context consists of information about the user directory and the contents of the directory that pertain to the authenticated user.
User context variables can be based on an attribute of a directory connection, or based on the contents of the directory. The key benefit of this type of variable is to provide flexibility in defining rules that are based on particular user context without any programming logic.
HTML forms are often used to collect information that back-end applications require. Form Post variables can be used to capture any information that is entered in an HTML form and POSTed. For example, if the business logic associated with an application requires a purchase order amount that is specified on an HTML login form, create a Form Post variable object to collect the value of the purchase order that the user supplies. The variable can then be used in policies.
Important: EJB and Servlet Agents do not support Form Post variables. Do not use Form Post variables in policies that are enforced by EJB or Servlet Agents.
The key benefit of this type of variable is that it allows the Policy Server to use POST data as a part of a policy expression rather than forcing enterprises to build security logic into HTML forms are often used to collect information that back-end applications require. Form Post variables can be used to capture any information that is entered in an HTML form and POSTed. For example, if the business logic associated with an application requires a purchase order amount that is specified on an HTML login form, create a Form Post variable object to collect the value of the purchase order that the user supplies. The variable can then be used in policies. server applications. Using HTTP POST variables results in efficient network usage between Agents and Policy Servers. The Agent extracts the HTTP variable information from the HTTP stream so that the information can be used during authorization processing by the Policy Server.
Web Services variables can be used to capture information retrieved from a Web Service for use in policies or responses. The key benefit of this type of variable is to allow a Policy Server administrator to define a policy based on the dynamic customer information provided in real time by a Web Service.
Variables allow you to include business logic in policies by capturing a wide range of dynamic data that can be built into policy expressions. When you define variable objects in the Administrative UI, you can use those variables in expressions in the Policy dialog on the Expression tab. You can build expressions that use multiple variable objects and boolean operators to capture complex business logic in your policies.
For example, a policy can contain an expression that requires the value of a user account type and a credit score to allow access to an application. An expression can be defined in the policy so that only users whose account type is “gold”, and whose credit score is greater than a specific value can have access to a resource. This example requires two variables, which must be combined in an expression.
Variables can be used in responses. When you define variable objects in the Administrative UI, you can use those variables in responses. The value of the response is created at runtime by the Policy Server as it resolves the value of a variable object.
|
Copyright © 2014 CA.
All rights reserved.
|
|