Configuring rules in authentication policies - PingFederate - 10.3

PingFederate Server

bundle
pingfederate-103
ft:publication_title
PingFederate Server
Product_Version_ce
PingFederate 10.3
category
Product
pf-103
pingfederate
ContentType_ce

PingFederate supports more granular control through the use of rules in authentication policies.

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. On the Rules window, select an attribute from the Attribute Name list.
  4. 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.

  5. In the Value field, enter the desired value to be compared against the attribute value from the authentication source.
  6. In the Result field, enter a unique label.
  7. Optional: To add another rule, click Add and repeat steps 3 to 6.
  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.
    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.