As needed, administrators can configure one or more authentication selector instances to evaluate conditions of the requests and define policies to route the request to a series of approved authentication sources or deny the request based on the results from the authentication selector instances, authentication sources, or both. Administrators can also reuse an authentication policy by ending it with an authentication policy contract or a local identity profile and then applying the authentication policy contract in multiple use cases.

A diagram of the OIDC, OAuth, and SAML authentication policies work flow. For details read the processing steps.

Processing steps

  1. A client initiated authentication request is sent to PingFederate.
  2. PingFederate evaluates the authentication policy, which defines the decision to route a request through a series of approved authentication sources.
  3. The authentication policy is mapped to the policy contract.

    The authentication policy determines how the user signs on and drives the authentication experience, such as form based authentication, Kerberos authentication, or MFA.

    Note:

    PingFederate can enforce authentication policies based on the requesting OAuth client as well as only enforce policy rules for authentication policy contract branches that are mapped to an access token manager (ATM). For more information, see Policies.

  4. For an OIDC/OAuth flow, the policy contract checks the attribute contract connected to authentication sources or datastores, or for a SAML connection, the policy contract checks the SAML connection tied to the policy contract.
    Important:

    For an OIDC authentication flow, you must set up an OIDC application in PingFederate. For more information, see Setting up an OIDC application in PingFederate.

  5. The authentication request either succeeds or fails based on the results of the policy evaluation and authentication requirements.