PingFederate Server

Defining authentication policies based on group membership information

PingFederate lets you configure authentication policies based on group membership information through the use of rules.

About this task

Assume 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 might prefer to roll out multi-factor 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 multi-factor 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)

Steps

  1. If you have not done so, create a new AD group, for example, CN=PingIDRequired,OU=IT,DC=example,DC=com, and place those two groups as members of the new group.

    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, after 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 window.

    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 window. For more information, see Defining the IdP adapter contract.

      A sample screenshot of the LDAP Directory Search window

  3. Go to Authentication → Policies → Policies. On the Policies window, select the applicable authentication policy.

  4. On the Policy window, 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. From the Attribute Name list, select memberOf.

    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 distinguished name (DN) of the new group created in step 1 in the Value field, such as CN=PingIDRequired,OU=IT,DC=example,DC=com.

    4. In the Result field, enter a label, for example, PingID users.

    5. Leave the Default to Success check box as selected.

      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.

      Example:

      Your Rules dialog should be similar to the following sample.

    A sample Rules dialog

  6. To close the Rules window, click Done.

  7. For the new HTML Form → PingID users policy path, select your PingID Adapter instance as the policy action from the list.

    To open the Incoming User ID dialog, click Options, underneath the PingID Adapter instance. Configure the source of the user ID required by the PingID Adapter, and then click Done to close the dialog. For more information, see Specifying incoming user IDs.

    Result:

    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.

    Result:

    Your policy should be similar to the following sample.

    A sample authentication policy with rules

  9. To close the Policy window, click Done.

  10. On the Policies window, click Save.

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