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

  • 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.
    Note:

    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 a 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.

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 the user is a contractor. Your organization mandates that all contractors must authenticate successfully against the OpenToken identity provider (IdP) adapter, followed by another IdP adapter, such as 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. Go to Authentication > Policies > Policies. On the Policies window, select the applicable authentication policy.
  2. On the Policy tab, locate the authentication source that you want to define additional successful results for further processing, and then click Rules underneath it.
  3. In the Rules window, select the source of the attribute from the Authentication Source list.Screenshot of Rules dialog
  4. Select an attribute from the Attribute Name list.

    The rule can use any attribute processed in a previous step of the policy.

    Authentication Source options Attribute Name options

    Previous authentication sources

    The attribute options depend on the previous authentication source.

    Extended Properties

    (available only if PingFederate has extended properties configured)

    The attribute options depend on which extended properties were configured.

    Tracked HTTP Parameters

    (available only if PingFederate has tracked HTTP parameters configured)

    The attribute options depend on which tracked HTTP parameters were configured.

    Context
    • Client ID for OAuth flows
    • Scope for OAuth flows
    • SP Connection Entity ID for SAML flows
    • Virtual Server ID for SAML flows
    • HTTP Request
    • Client IP

    Expression

    When you select Expression as the Authentication Source, enter an OGNL expression in the field. The expression can reference upstream attributes, extended properties, tracked parameters, and context. When the expression's boolean result is true, PingFederate returns the rule's Result value. When the expression's boolean result is false, PingFederate evaluates the next rule.

    To test an expression rule, click Test. Then use the Test Expression dialog to test the expression with different values.

    CAUTION:

    Policy rules that have overly restrictive expressions or expressions with wildcards might result in denial-of-service or unauthorized access.

    Fragment

    The attribute options depend on the fragment’s output contract. If a fragment does not have an output contract, then the fragment will not be selectable as an authentication source option.
  5. From the Condition list, 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.
    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 whether an attribute contains or does not contain the specified value in its attribute list.

    CAUTION:

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

  6. In the Value field, enter the desired value to be compared against the attribute value from the authentication source.
  7. In the Result field, enter a unique label.
  8. Optional: To add another rule, click Add and repeat steps 3 to 7.
    Tip:

    If there are multiple rules, you can use the drag handle icon The drag handle icon to change the order of the rules. PingFederate evaluates the rules in the order you place them.

  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.
    Note:

    The Default to Success check box is selected by default. When you clear this check box, the policy engine treats the attempt as a failure when no rules return a match.

  10. To close the Rules window, click Done.

    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 window, continue with the rest of your policy configuration.