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