Policy-Backed Identity Providers

A Policy-Backed Identity Provider authenticates a user based on the logic provided by the underlying policy fragment. This allows you to create authentication logic that is as complex or as basic as you need. You can even validate and authorize the user.
gateway83
A Policy-Backed Identity Provider authenticates a user based on the logic provided by the underlying policy fragment. This allows you to create authentication logic that is as complex or as basic as you need. You can even validate and authorize the user.
In use, validating against a Policy-Backed Identity Provider works like validating against the built-in identity providers in the Require XPath Credentials Assertion).
Unlike the other identity providers, a Policy-Backed Identity Provider is not prepopulated with a list of authorized users. In fact, the 
CA API Gateway
does not need to know whether the user exists or if that person will ever log on to the Gateway. You only need to configure template users based on a user name and optionally assign a role. When a user with a matching username is authenticated, he or she is allowed access to the Policy Manager based on the features permitted by that role.
Examples of where a Policy-Backed Identity Provider can be useful: contacting a Web service, using a custom assertion for a protocol such as RADIUS, or custom LDAP or JDBC authentication.
The Policy-Backed Identity Provider only authenticates individual users, not groups.
Backing Policy
The underlying policy fragment ("backing policy") receives these prepopulated variables containing the user's credentials:
  • ${idp.userid}
    : Returns the user's ID.
  • ${idp.password}
    : Returns the user's password.
The backing policy can contain any number of assertions to authenticate the username and password. The only thing to keep in mind is that the policy must not be able to succeed without authenticating the user.
The following is a very simple policy fragment that compares the username with "joe" and the password with "password":
Policy_Backed_Provider_simple_backing_policy.png
This example uses the Compare Expression Assertion.
Hints and Tips 
  • A Policy-Backed Identity Provider is appropriate for you if you need both of the following:
    • You require password authentication implemented by a custom policy that will authenticate the credentials based on username and password.
    • Ability for users authenticated via this policy to log in to the Policy Manager (or the Management API) and administer the 
      API Gateway
      , or use at least one of the 
      API Gateway
       built-in services (for example, policy discovery or token service).
  • If your authentication requirements do not require Policy Manager login or use of built-in services (in other words, users are only used in message processing traffic), consider using an encapsulated assertion or included policy fragment instead.
  • If you do not require custom policy behavior during authentication, consider authenticating against an LDAP server or the Internal Identity Provider instead.
  • Create a Policy-Backed Identity Provider only if you need an identity provider. If you only need a reusable policy snippet that hides its implementation details, use an encapsulated assertion instead.
  • A Policy-Backed Identity Provider can be used with the Authenticate Against Identity Provider and Authenticate User or Group assertions like any other identity provider.
  • It is possible to embed one of the above "Authenticate...." assertions within the backing policy of a Policy-Backed Identity Provider and then have that "Authenticate..." assertion authenticate against another identity provider (for example, LDAP or Federated). However, such a configuration is recommended only for advanced users and may be more difficult to troubleshoot.