An authentication source in an authentication policy has two results, Fail or Success, for which one of the following actions can be set:

  • Append another authentication source for further processing
  • Append a selector for further processing
  • Select Done to terminate the authentication policy (making it a closed-ended path)
  • Select an authentication policy contract or a local identity profile (also terminating the authentication policy, making it a closed-ended path)
    Tip: A policy path is closed-ended if it contains one or more authentication sources (with or without any selector instances). A closed-ended path can optionally end with an authentication policy contract or a local identity profile.

    A policy path is also closed-ended if it ends with an instance of a custom authentication selector that returns an IdP adapter instance ID or the connection ID of an IdP connection. Because the custom selector returns an authentication source, such closed-ended path cannot end with an authentication policy contract or a local identity profile. (Instead, it must end with an action of Done or Restart.)

PingFederate supports more granular control through the use of rules in authentication policies. By applying multiple rules to an authentication source, an administrator can define additional (successful) results based on attribute values from the authentication source and set different action for each result.

For example, your OpenToken IdP Adapter instance returns an attribute (EmployeeType) that identifies the employee profile; a value of temp indicates such user is a contractor. Your organization mandates that all contractors must authenticate successfully against the OpenToken IdP adapter, followed by another IdP adapter (for example, an instance of the PingID® Adapter for multifactor authentication). To fulfill this authentication requirement, you can define a successful result by adding a rule to evaluate the EmployeeType value, and then select the PingID Adapter instance as the action for this match.

When multiple rules exist for a given authentication source, the first match wins. If no rule returns a match, administrators have the option to treat the authentication as successful or failure.

  1. On the Authentication Policies screen, select the applicable authentication policy.
  2. On the Policy screen, locate the authentication source that you want to define additional successful results for further processing and then click Rules underneath it.
  3. On the Rules dialog select an attribute from the Attribute Name list.
  4. Select how PingFederate should compare the value that you are going to specify in the next step against the attribute value from the authentication source in the Condition list.
    The choices are:
    • 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

    Use one of the first six choices only for attributes consisting of a single value.

    Use the multi-value conditions when you want PingFederate to verify that an attribute contains or does not contain the specified value in its attribute list.


    Using a single-value condition when an attribute has multiple values causes the condition to evaluate consistently to false.

  5. Enter the desired value to be compared against the attribute value from the authentication source in the Value field.
  6. Enter a unique label in the Result field.
  7. Optional: Click Add and repeat steps 3 to 6 to add another rule.
  8. If any individual rule is no longer required, select the Delete action.
  9. Select the Default to Success check box if you want the policy engine to treat the authentication attempt as successful when no rules return a match.
    By default, this check box is selected. When cleared, the policy engine treats the attempt as a failure when no rules return a match.
  10. Click Done to close the Rules dialog.

    Your policy is now updated with a new policy path (or paths if you have added multiple rules).

    For instance, if you have added two rules with labels Contractors (the first rule) and Senior executives (the second rule) to an authentication source, you should see the following results in the policy:

    • Fail
    • Contractors (a new result based on the first rule)
    • Senior executives (a new result based on the second rule)
    • Success (available only when the Default to Success check box is selected)
  11. On the Policy screen, continue with the rest of your policy configuration.