You can configure an Identifier First Adapter instance to determine user populations based on user identifiers ("usernames") and an authentication policy to route sign-on requests to authentication sources tailored for their respective user populations. Consider the following sample use case.

You are tasked to enforce different sets of authentication requirements for two sets of users, employees and external consultants.

Employees are given username@example.com email addresses; for example, asmith@example.com. User records are stored in a local directory server. Employees sign on through an HTML Form Adapter instance.

On the other hand, consultants have either username@example.org or username@example.info email addresses. User records are stored in a local database. Consultants can sign on using their username or email address (and password) through a local web portal. This web portal is integrated with PingFederate using the OpenToken framework.

Your organization owns another local database that keeps track of username, domain information, and email address for both employees and consultants. The column names are dsUid, dsDomain, and dsMail, respectively. For simplicity, no users share the same dsUid value.

In this sample use case, you must ensure that the Identifier First Adapter instance can handle the scenario where users may enter their email address or just their username when setting up the Identifier First Adapter instance. Additionally, when accessing protected resources, your organization have agreed to send the user's email address in the security token.

You have already created the following components:

  • An LDAP datastore connecting to the local directory server. The attribute name of the user identifier is uid.
  • An instance of the LDAP Username Password Credential Validator (PCV) validating credentials against the local directory server via the LDAP datastore. The LDAP Username PCV instance is extended with an additional attribute mail. The search filter is configured to handle identifiers in the format of an email address or a username; for example:


                         (|(uid=${username})(mail=${username}))
                      

  • An HTML Form Adapter instance delegating credential-validation to the LDAP Username PCV instance. The HTML Form Adapter instance is also extended with an additional attribute mail, which takes the mail attribute value from the LDAP Username PCV instance. The ID of this HTML Form Adapter instance is htmlForm.
  • An OpenToken IdP Adapter instance digesting tokens from the web portal as the source of user attributes. The adapter contract is extended with an additional attribute mail. The web portal is designed to always include the user's email address in the token through the mail attribute. The ID of this OpenToken IdP Adapter instance is opentTokenIdp.

This sample use case requires the following additional components:

  1. An expression-enabled PingFederate environment (step 1).
  2. An authentication policy contract to carry the email address from your organization to your partners (step 2).
  3. A JDBC datastore connecting to the database that hosts username, email, and domain information (step 3).
  4. An Identifier First Adapter instance with an attribute source lookup configuration and a contract fulfillment via expressions for the domain adapter attribute (step 4).
  5. An authentication policy to route user requests to different authentication sources based on user populations (step 5).

To fulfill the requirements:

  1. Enable expressions in PingFederate.

    For configuration steps, see Enabling and disabling expressions.

  2. On the Identity Provider > Policy Contracts screen, create an authentication policy contract without any additional attributes.
  3. On the System > Data Stores screen, create a JDBC datastore connection to the database that hosts username and domain information.
  4. Create an instance of the Identifier First Adapter instance.
    1. Follow steps 1 through 6 in Configuring an Identifier First Adapter instance.

      Suppose you name the adapter instance ID 1st.

    2. On the Adapter Contract Mapping screen, click Configure Adapter Contract.
    3. On the Attribute Sources & User Lookup screen, click Add Attribute Source.
      Let the administrative console guide you to complete the Attribute Sources & User Lookup configuration.
      1. On the Data Store screen, enter an ID and a name for the attribute source; for example, domainInfo and Domain Info, respectively. Then select the JDBC datastore created in step 3.
      2. On the Database Table and Columns screen, select the applicable schema and table. Then select the dsDomain column and click Add Attribute.
      3. On the Database Filter screen, specify a filter to search by identifier that can handle identifiers in the format of an email address or a username; for example:


                                         dsUid='${subject}' OR dsMail='${subject}'
                                      

      For more information about each step, see Datastore query configuration.

    4. On the Adapter Contract Fulfillment screen, configure as follows.
      Contract Source Value
      domain Expression
      
      #this.get("domain").toString().matches("(?i).+") ? 
      #this.get("domain") : 
      #this.get("ds.domainInfo.dsDomain")
      Note:

      Line breaks are inserted for readability only.

      subject Adapter Not applicable. (No selection is required.)

      The expression checks the domain attribute value returned by the Identifier First Adapter. If the value contains one or more character, PingFederate uses that as the value for the domain attribute; otherwise, it uses the dsDomain column value returned from the JDBC datastore. In order words, this expression handles identifiers in the format of an email address or a username.

      This sample expression is intended to demonstrate the capability of the Identifier First Adapter. Depending on the actual use cases, expressions may vary. For more information about expressions, see Construct OGNL expressions.

    5. On the Issuance Criteria screen, click Next.
      Depending on the actual use cases, you may add one or more issuance criteria.
    6. On the Summary screen, review and save your adapter instance configuration.
  5. Create an authentication policy with rules to form policy paths based on results from domain attribute values returned by the Identifier First Adapter.
    1. On the Identity Provider > Policies screen, click Add Policy.
    2. On the Policy screen, enter a name (and optionally a description) for the policy.
    3. Select the Identifier First Adapter instance created in step 4.
    4. Click Rules to open the Rules dialog.
    5. Add three rules as follows.
      Attribute Name Condition Value Result
      domain equal to example.com Example COM
      domain equal to example.org Example ORG
      domain equal to example.info Example INFO

      In general, add one rule for each expected domain attribute value.

    6. Clear the Default to Success check box to disable the option to specify a policy path for the scenario where the domain attribute value from the Identifier First Adapter instance does not match any configured value on the Rules dialog.
      If you want to enable an authentication policy path for unexpected domain attribute values, leave the Default to Success check box as selected.

      For more information about rules, see Configuring rules in authentication policies.

    7. Click Done to close the Rules dialog.

      By adding three rules and disabling the default to success option, the Identifier First Adapter instance now contains four policy paths: Fail, Example COM, Example ORG, and Example INFO.

    8. Configure each policy path.
      Fail
      Select Done, which terminates the request in an error condition.
      Example COM
      Select the HTML Form Adapter instance, which contains two paths: Fail and Success.
      Configure each policy path.
      Fail
      Select Done, which terminates the request in an error condition.
      Success
      Select the policy contract created in step 2.

      Click Options to open the Incoming User ID dialog.

      1. Select Adapter (ID 1st) under Source.
      2. Select subject under Attribute.
      3. Click Done to close the Incoming User ID dialog.

      For more information, see Specifying an incoming user ID.

      Example ORG (and then Example INFO)
      Select the OpenToken IdP Adapter instance, which contains two paths: Fail and Success.
      Configure each policy path by using the same steps documented for the Example COM policy path
    9. Configure contract fulfillment for each authentication policy contract as follows.
      Result from rules Contract Attribute Source Value
      Example COM subject Adapter (htmlForm) mail
      Example ORG subject Adapter (openTokenIdp) mail
      Example INFO subject Adapter (openTokenIdp) mail

      For more information, see Configuring contract mapping.

    10. Click Done and then Save.

You have now successfully configured an Identifier First Adapter instance and an authentication policy to prompt the user for their identifier first, determine their user population, and route the request to the desired authentication policy path.