PingFederate Server

Token authorization

PingFederate provides an optional configuration known as token authorization to evaluate user attributes as well as other runtime variables, such as authentication context, for authorization purposes.

Token authorization provides a way for administrators to extend access policy directly to many areas, such as browser single sign-on (SSO), security token service (STS), and OAuth events, by conditionally allowing or disallowing the issuance of relevant security tokens such as SAML assertions, STS tokens, OAuth access tokens, or session cookies. The option is also available for extending authorization policy to attribute-query responses, identity provider (IdP) adapter contracts, and authentication policy contracts.

Administrators can configure token authorization using Issuance Criteria windows immediately following the configuration of attribute mapping at all applicable points in the administrative console. See Defining issuance criteria for IdP Browser SSO as an example.

Issuance criteria

The token-authorization configuration consists of rules that evaluate attribute values against selected conditions. Depending on the type of configuration that contains the token-authorization setup, choose from among several sources for the attributes. The sources always consist of all of those available for attribute mapping, including configured data stores and runtime information related to the context of an event. In addition, the sources use values of mapped attributes to provide access to any plain-text mappings or the runtime results of any attribute mapping expressions.

When more than one condition is configured, all are evaluated and all the conditions must be met at runtime (evaluated as true) for authorization to succeed and processing to continue. In cases where you might need “or” conditions or layered evaluations, you can create one or more attribute mapping expressions.

When authorization fails and a transaction halts, the system passes back a configurable Error Result code, potentially to an application layer or as a variable on a PingFederate user-facing template. How this code is interpreted depends on the use case and application integration.

Single and multivalued conditions

Each token-authorization configuration provides a choice of conditions for evaluating attribute values:

  • equal to

  • equal to (case insensitive)

  • equal to DN

  • not equal to

  • not equal to (case insensitive)

  • not equal to DN

  • multi-value contains

  • multi-value contains (case insensitive)

  • multi-value contains DN

  • multi-value does not contain

  • multi-value does not contain (case insensitive)

  • multi-value does not contain DN

The first six conditions are intended for single-value attributes. Use one of the multi-value …​ conditions when you want PingFederate to validate whether one of the attribute values matches or does not match the specified value. Using a single-value condition when an attribute has multiple values causes the criteria to fail consistently.