The web application defines the requirements for Identity Injection. If a web application has been configured to look for certain fields in the header and the information cannot be found, the web application determines whether the user is denied access, granted access, or redirected. Configure an Identity Injection policy to inject the required information into the HTTP header.
Click Access Gateways > Edit > [Reverse Proxy Name] > [Name of Proxy Service] > Protected Resources > [Name of Protected Resource] > Identity Injection.
The Identity Injection Policy List contains all the Identity Injection policies that have been created on this Administration Console for the selected policy container.
Select one of the following:
To enable an existing policy, select the policy, then click Enable. Only the policies that are enabled are applied to this resource. Continue with Step 4.
To disable an existing policy, select the policy, then click Disable. Continue with Step 4.
To edit an existing policy, click the name of the policy. Remember that policies can be assigned to multiple protected resources. Modifying a policy also affects how this policy protects those resources. For more information, see Identity Injection Policies.
Continue with Step 4.
To create a new policy, click Manage Policies. On the Policies page, click New, specify a display name, select Access Gateway: Identity Injection as the type, then click OK. For configuration information, see Section 6.4, Identity Injection Policies.
Continue with Step 3.
To enable the policy you just created, select the policy, then click Enable.
Only the policies that are enabled are applied to this resource. If you use the same policy for multiple protected resources, use the policy description field to indicate this.
To save your changes to the browser cache, click OK.
To apply your changes, click the Access Gateways link, then click Update > OK.
IMPORTANT:If you enable an Identity Injection policy for a protected resource that has been assigned to use a contract that does not prompt the user for a password and the Identity Injection policy injects the user’s password, single sign-on cannot be enabled because the password is not available. However, you can create a contract that retrieves the user’s password when the user is not prompted for a password when authenticating. See Password Retrieval.