Before setting up an Identity Injection policy, you need to know the following about your web application:
Does it require an authentication header? Does this header need just the username or does it also need the password?
Does it use a custom header with custom names (x-names)? If so, you need to know their names and their expected values.
Does the custom header require any custom names (x-names) with tags? If so, gather this information.
Does the application expect specific values in the query string of the URL? If so, gather this information.
Does it require the authentication information from the Kerberos tickets? If so, gather this information.
Does the application require Access Gateway to fetch OAuth token and pass it over to the header? If so, gather this information.
After gathering the information, you need to determine whether you need to create one policy with one rule, one policy with multiple rules, or multiple policies. If you have multiple applications that require the same type of authentication header, you might want to create an authentication header policy and separate policies for the application-specific information. You can then enable both the authentication header policy and the application-specific policy for the resource that is protecting the application. You must design your policies so that the application receives just what it needs. It must not inject custom names and values it does not use.
Everything defined in a policy is injected into the header, even if the values are empty because Access Manager could not obtain the value for the item. For some applications, this is still useful information and the application uses it to make access decisions.
Whether you create a policy with one rule or multiple rules is a personal design decision. If you put all the actions in one rule, you have only one description field to describe the function of the policy. If you put each action type in a separate rule, you have multiple description fields to describe the function of the policy. Select the method that is easiest for you.
Rules are evaluated by priority. The first rule that is evaluated with an authentication header is processed, and the authentication header is rejected if it is found in any of the other rules. Your policy can inject only one authentication header, one cookie header, and one query string, but it can inject multiple custom headers and custom headers with tags.
Identity Injection policies are processed when a user requests access to a resource. The results and the values of the data items are cached for the user session. This means that when the user requests a second time to access the resource, the policy is evaluated, but 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 back in to trigger new data values. (For information about how long the data items are cached, see Section 32.6.3, The Policy Is Using Old User Data.)
The LDAP Attribute and the Shared Secret actions can be configured to refresh their values. This means the attribute or secret value is read not just on the first request that triggers the policy evaluation, but when the specified refresh interval expires. You can select to cache the value for the session, for the request, or for a time interval varying from 5 seconds to 60 minutes.
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 Identity Injection policy that grants access based on an LDAP attribute in a custom header having a “yes” value. Users with a “no” value in custom header are denied access.
If you don’t enable the Refresh Data option on this attribute in the policy, 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, 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 specified interval has expired, the Refresh Data option causes the value of the attribute to be read again from the LDAP server. This new value is injected into the custom header, and any other policy that is triggered by the request and uses the new value for its policy.
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 and secret store values are normally cached for the user session. Enable this option only on those attributes and secrets that are critical to the security of your system or to the design of your work flow.