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.
You need to enforce different sets of authentication requirements for two sets of users, employees, and external consultants.
Employees are given username@example.com email addresses, such as asmith@example.com. User records are stored in a local directory server. Employees sign on through an HTML Form Adapter instance.
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 make sure that the Identifier First Adapter instance can handle the scenario where users might enter their email address or just their username when setting up the Identifier First Adapter instance. Additionally, when accessing protected resources, your organization has 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 with 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. See the following code 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. See step 1.
- An authentication policy contract to carry the email address from your organization to your partners. See step 2.
- A Java Database Connectivity (JDBC) datastore connecting to the database that hosts username, email, and domain information. See step 3.
- An Identifier First Adapter instance with an attribute source lookup configuration and a contract fulfillment via expressions for the domain adapter attribute. See step 4.
- An authentication policy to route user requests to different authentication sources based on user populations. See 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.