Configuring a policy for multiple user populations - PingFederate - 10.2

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 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.
• 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

Configure:

• 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.

For the configuration steps, see the subsequent task.