Some authentication sources make use of a user identifier at request time; for example:
- The PingID® Adapter requires a user ID to be passed in from an earlier-authentication step to perform multifactor authentication.
- The HTML Form Adapter and custom IdP adapters developed using the
IdpAuthenticationAdapterV2interface from the PingFederate SDK can pre-populate username information based on an incoming user ID.
- A SAML 2.0 IdP connection can use an incoming ID to specify the Subject value in its authentication requests.
- An OpenID Connect IdP connection can leverage an incoming user ID to specify a login_hint parameter value in its OAuth authorization requests.
To address these use cases, use thedialog to specify the source and the attribute of the incoming user ID in an authentication policy.
You can select any IdP adapter instance or IdP connection that has been placed in the same policy path ahead of the current authentication source to be the source of the incoming user ID. After selecting a source, choose an attribute from the selected IdP adapter contract or IdP connection. At runtime, the attribute value becomes the incoming user ID.
Alternatively, you can use the originating SAML 2.0, WS-Federation, or OpenID Connect authentication request as the source. In this scenario, the incoming user ID is derived from the Subject element in a SAML 2.0 authentication request, the username parameter in a WS-Federation authentication request, or the login_hint parameter in an OpenID Connect authentication request.
- On the screen, select the applicable authentication policy.
- On the Options underneath it. screen, locate the authentication source that you need to provide an incoming user ID and then click
On the Incoming User ID dialog, select the source of the
incoming user ID from the Source list.
If you want the policy engine to derive the incoming user ID from the originating SAML 2.0 or WS-Federation authentication request, select Context.
Select an attribute of the incoming user ID from the
If you have selected Context in the previous step, select Requested User to derive the incoming user ID from the Subject element, the username parameter, or the login_hint parameter in the SAML 2.0, WS-Federation, or OpenID Connect authentication request, respectively.
If a request does not originate from a SAML 2.0, WS-Federation, or OpenID Connect authentication request, or if the SAML 2.0, WS-Federation, or OpenID Connect authentication request does not include the optional Subject element, username parameter, or login_hint parameter, the policy engine advances without providing username information to the authentication source.
- Click Done to close the Incoming User ID dialog.
- On the Policy screen, continue with the rest of your policy configuration.