PingFederate provides the capability to configure authentication policies based on group membership information through the use of rules.

Suppose you have created the following authentication policy to enforce multifactor authentication using PingID® after the users have successfully authenticated against an HTML Form Adapter instance:

A sample authentication policy without rules

While this policy satisfies the authentication requirements, you prefer to roll out multifactor authentication based on group membership over a period of time. To accomplish this policy deployment strategy, you can use rules to define the applicable groups and set different policy actions accordingly.

As an example, suppose you want to enforce PingID multifactor authentication to two Active Directory (AD) groups:
  • CN=helpdesk,OU=IT,DC=example,DC=com (IT helpdesk personnel)
  • CN=leads,OU=IT,DC=example,DC=com (Leaders in the IT department)
  1. If you have not done so, create a new AD group (for instance, CN=PingIDRequired,OU=IT,DC=example,DC=com) and place those two groups as members of the new group.
    Tip:

    Generally speaking, this step streamlines the process of deploying your authentication policies to additional groups of users later. In other words, when you are ready to roll out your authentication policies to more users, simply add the applicable groups as members of the new group. This way, you are not required to make any changes to the authentication policies (once they are configured).

  2. If you have not done so, follow these steps to extend the HTML Form Adapter instance to return group membership information from your AD.
    1. Extend the HTML Form Adapter instance with the memberOf attribute on the Extended Contract screen.
    2. Configure PingFederate to fulfill the memberOf attribute from your AD.
      Because the actual groups are nested inside the new group created in step 1, configure the IdP adapter contract to pull the memberOf attribute values with nested groups on the LDAP Directory Search screen.
      A sample screenshot of the LDAP Directory Search screen

      (For more information, see Defining the IdP adapter contract.)

  3. On the Authentication Policies screen, select the applicable authentication policy.
  4. On the Policy screen, click Rules underneath the HTML Form Adapter instance.
  5. In the Rules dialog, add a rule to check for membership information obtained from the HTML Form Adapter instance.
    1. Select memberOf from the Attribute Name list.
    2. Select how PingFederate should compare the value that you are going to specify in the next step against the attribute value from the HTML Form Adapter instance; for example, multi-value contains DN works well for the memberOf AD user attribute.
    3. Enter the DN of the new group created in step 1 in the Value field; for example, CN=PingIDRequired,OU=IT,DC=example,DC=com.
    4. Enter a label in the Result field; for example, PingID users.
    5. Leave the Default to Success check box as selected.
      Note:

      When the Default to Success check box is selected, you can set the action for the scenario where none of the rules returns a match.

    Your Rules dialog should be similar to the following sample:

    A sample Rules dialog
  6. Click Done to close the Rules dialog.
  7. For the new HTML Form > PingID users policy path, select your PingID Adapter instance as the policy action from the list.
    Click Options (underneath the PingID Adapter instance) to open the Incoming User ID dialog. Configure the source of the user ID required by the PingID Adapter, and then click Done to close the dialog (see Specifying an incoming user ID).

    Your policy should be similar to the following sample:

    A sample Rules dialog

    There are four policy paths:

    • HTML Form > Fail
    • HTML Form > PingID users > Fail
    • HTML Form > PingID users > Success
    • HTML Form > Success
  8. Update your policy as follows:
    HTML Form > Fail
    Leave Done as the policy action. At runtime, PingFederate terminates the request and returns an error message to the user.
    HTML Form > PingID users > Fail
    Select Done as the policy action. At runtime, PingFederate terminates the request and returns an error message to the user.
    HTML Form > PingID users > Success
    Select an authentication policy contract as the policy action. Click Contract Mapping to complete its fulfillment. At runtime, PingFederate fulfills the authentication policy contract and carries on with the request.
    HTML Form > Success
    Reconfigure the policy action for this policy path. Select an authentication policy contract as the policy action. Click Contract Mapping to complete its fulfillment. At runtime, PingFederate fulfills the authentication policy contract and carries on with the request.

    Your policy should be similar to the following sample:

    An sample authentication policy with rules
  9. Click Done to close the Policy screen.
  10. On the Authentication Policies screen, click Save.
Note:

Group membership is only one of the possible factors that you can use to define additional policy paths and their policy actions. Generally speaking, you can use any attributes available from the authentication source when configuring rules.