In the context of Policy Server, variables are objects that can be resolved 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 processed by CA SiteMinder® establishes a request context. This context identifies the following:
Indicates the type of action specified in the request, such as GET or POST.
Indicates the requested resource, such as /directory_name/.
Indicates the full server name specified in the request, such as server.example.com.
A request context variable may capture any of this information and 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 based on particular user context without any programming logic.
HTML forms are often used to collect information required by back-end applications. Form Post variables can be used to capture any information entered in an HTML form and POSTed. For example, if the business logic associated with an application requires a purchase order amount specified on a HTML form used for logging into the application, you can create a Form Post variable object that collects the value of the purchase order supplied by a user. The variable can then be used in policies.
Important: Form Post variables are not supported by EJB or Servlet Agents. Do not use Form Post variables in policies 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 back end server applications. Using HTTP POST variables results in efficient network usage between Agents and Policy Servers. The Agent only needs to extract the HTTP variable information from the HTTP stream so that the information can be used during authorization processing by the Policy Server.
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 may 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 very complex business logic in your policies.
For example, a policy may contain an expression that requires the value of a user’s account type and a credit score in order 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 may have access to a resource. This example requires two variables, which must be combined in an expression.
Note: Variables can only be used in policy expressions when using traditional (policy domain-based) policy management. They are not available when using enterprise (application-based) policy management.
Variables are objects that can be resolved 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 run time.
To make authorization decisions based on the transport header, SOAP envelope header, XML payload, or SAML assertions, you can define specific CA SiteMinder® Web Services Security variables and add them to policies in the form of policy expressions. The Policy Server can use a policy expression as an additional criterion when determining if a client should be permitted access to a web service.
CA SiteMinder® Web Services Security provides five variables types that represent dynamic, context-sensitive data from any layer (transport, message envelope, or message body) of an XML message. All of these variables can be used in policy expressions.
Once defined, these variables can be used in policy expressions to make authorization decisions. For example, you could define an XML body variable called ShipToZipCode that corresponds to an XML query that obtains the ship-to ZIP code from a purchase order XML document.
Variables may 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 © 2013 CA.
All rights reserved.
|
|