Policy variables

Use policy variables to resolve tokens of the form {$Variable_name} that can appear in the URL pattern setting of a proxy rule or in metadata.

Policy variables are used in the urlPattern setting of a proxy rule item, or in a metadata section. There are two types of policy variables:

Endpoint variables

Endpoint variables define a single-value variable. They are typically used to define a specific backend host. When application developers use endpoint variables, they can write a policy rule so that it extracts those parts of the URL pattern in a variable specific to the current portal environment. Example:

1. The portlet developer defines a proxy rule with the following URL pattern setting: {$my_server}/mymail*. This means the resulting URL pattern is the value of the policy variable, appended with the path /mymail.

2. The portal system administrator defines the value http://www.the-remote-system.com for the variable my_server. Therefore, the URL pattern of the policy rule is http://www.the-remote-system.com/mymail.

The benefit of this technique is we can divide a URL pattern into parts that are owned by the portlet developer and parts that are owned by the portal system administrator. Therefore, the portlet developer can define a policy rule without knowing the concrete host name of the backend system to which the outbound connection is established.

Dynamic policy variables

Dynamic policy variables can have more than one value. The purpose of this variable type is to define dynamic parts of the URL pattern without having to specify a policy rule more than once. Example:

• A policy rule URL pattern has the following URL pattern setting: http://localhost/wps/{$my_dynamic_policy}/Main/*.

• The variable my_dynamic_policy is associated with the values portal and myportal.

As a result, the policy rule applies to URLs that start with http://localhost/wps/portal/Main/ or http://localhost/wps/myportal/Main/. The purpose of this technique is to make one policy rule available for multiple URL patterns that can contain dynamic parts.

The following list gives some hints and tips for working with policy variables:

Mixing and Nesting of Policy variables:

We can nest policy variables. For example, we can specify the name of a policy variable as a value of a policy variable. We can also specify more than one policy variable in one URL pattern. The following example is a more complex example of a URL pattern that uses multiple policy rules:

• The following policy variables are defined:

  name=PROTOCOL
  type=Dynamic Policy Values= http, https
   name = CONTEXT_ROOT
  type = Dynamic Policy Values = wps/portal, wps/myportal
   name=HOSTNAME
  type=Endpoint
  Value={$PROTOCOL}://www.my-remote-server.com

• The URL pattern of the policy rule has the following value: {$HOSTNAME}/{$CONTEXT_ROOT}/Mail*

The URL pattern is applicable for URLs that match with the following patterns:

http://www.my-remote-server.com/wps/portal
http://www.my-remote-server.com/wps/myportal
https://www.my-remote-server.com/wps/portal
https://www.my-remote-server.com/wps/myportal

Runtime resolution of policy variables:

There are also cases where an application developer wants to set the policy variable directly by the application. Example: An application wants to choose the credential slot ID of an authenticated HTTP connection. For these scenarios, the outbound HTTP connection infrastructure provides a means to specify policy variables at run time. There are two ways to define policy variables for runtime resolution:

• The policy variable is defined as a dynamic-policy variable.

• The policy variable is defined as an endpoint variable. Its value is empty. At run time, the client sets the policy variable value. The value is not validated.

Security note: Define runtime policy variables carefully. Run time policy variables can have a security impact. Example: The portal administrator wants to define two different user credentials for an outbound HTTP connection to the URL http://www.myremotehost.com/test. The user wants to select the credentials when the connection is created. A configuration defines the following policy variable:

name=SLOTID
type=Dynamic Policy Values= MySlot2, MySlot33

The variable is referenced by the Credential Vault slot description defined in the metadata section of a policy mapping /myproxy as illustrated later:

metadata name:  paa.slotid
metadata value: {$SLOTID}

At run time, the client submits the following request at the Ajax proxy:

HTTP://localhost/wps/myproxy/www.myremotehost.com/test?SLOTID=MySlot2

At run time, the authentication filter of the outbound HTTP connection server reads the metadata paa.slotid to get the slot ID for the credentials to be used for the outbound HTTP connection. The value of paa.slotid is mapped to the policy variable SLOTID. The client that called the connection defined a slot ID value MySlot2, which is in the valid set of policy variables.

Parent Configuration structure