This topic provides an overview for configuring an Identifier First Adapter instance with an authentication policy for multiple user populations using a sample use case.
To set up the Identifier First Adapter with an authentication policy for multiple user populations:
For this sample use case, consider the following:
- You need to enforce different sets of authentication requirements for two sets of users, employees, and external consultants.
- Employees are given email@example.com email addresses, such as firstname.lastname@example.org. User records are stored in a local directory server. Employees sign on through an HTML Form Adapter instance.
- Consultants have either email@example.com or firstname.lastname@example.org 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
dsMail, respectively. For simplicity, no users share the same
- 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 has agreed to send the user's email address in the security token.
Before you begin
- An LDAP datastore connecting to the local directory server. The attribute name
of the user identifier is
- 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
- An HTML Form Adapter instance delegating credential-validation to the LDAP
Username PCV instance. The HTML Form Adapter instance is also extended with an
- 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
For the configuration steps, see the subsequent task.