Authorization policies are processed when a user requests access to a resource. Results and values of the data items are cached for the user session. When a user requests a second time to access the resource, the policy is evaluated. However, the data values from the first evaluation are used. When a data item is cached for the user session, the user must log out and log in to trigger the new data values. For information about how long the data items are cached, see The Policy Is Using Old User Data.
The LDAP Attribute can be configured to refresh its value according to a specified interval. This means the attribute value is read not just on the first request that triggers the policy evaluation, but when the interval expires. You can select to cache the value for the user session, the current request, or a time interval varying from 5 seconds to 60 minutes.
If the requested page contains links, you must usually cache the data for more than a single request. Each link on the page generates a new request.
You can use this feature for situations when you do not want to force the user to log in again to gain rights to resources or to revoke rights to resources. For example, suppose that you have an Authorization policy that grants access based on an LDAP attribute having a “yes” value. Users with a “no” value in this attribute are denied access.
If you don’t enable the Refresh Data option on this attribute in the policy condition, the policy is evaluated when the user first tries to access the resource. The value for the attribute is cached for the user session, and until the user logs out, that is the value that is used.
However, if you enable the Refresh Data option on this attribute in the policy condition, the policy is evaluated when the user first tries to access the resource. When the user sends a second request to access the resource and the cached value has been marked old, the Refresh Data option causes the value of the attribute to be read again from the LDAP server. This new value is used to evaluate the policy and any other policy that is triggered by the request.
If the value from the first request to the second request changes from no to yes, the user gets access to the resource.
If the value from the first request to the second request changes from yes to no, the user is denied access to the resource.
For example:
If the attribute controls access to employee resources and an employee leaves, a quick change of this attribute value cuts the employee off from the resources that must be available to employees only.
If the attribute controls access to a software download site and a user has just purchased a product, a quick change to this attribute value can grant access to the download site.
IMPORTANT:This feature needs to be used with caution. Because querying the LDAP server slows down the processing of a policy, LDAP attribute values are normally cached for the user session. Enable this option only on those attributes that are critical to the security of your system or to the design of your work flow.