Mapping OAuth attributes
Mapping OAuth attributes is a two-stage processing workflow.
The two stages of mapping OAuth attributes include:
Stage 1 - Map from authentication sources, such as IdP adapter instances or IdP connections, authentication policy contracts, or Password Credential Validator instances (for resource owner credentials) to persistent grants
Stage 2 - Map from persistent grants, authentication sources, authentication policy contracts, authentication context, or Password Credential Validator instances to access tokens
This two-stage mapping workflow is different from other mapping scenarios in PingFederate, which involve just a one-phase configuration. |
The first stage
To accomplish the first stage, setting up persistent grants requires mapping, including a user key and all extended attributes.
The mappings use attributes obtained during initial authentication events within PingFederate, namely attributes from IdP adapter instances, attributes from assertions through IdP connections, attributes from authentication policy contracts, or attributes returned by password credential validator instances. Configure data store queries to accomplish different tasks, such as retrieving the user identifier from an LDAP directory server as the user key.
The |
The second stage
The second mapping configuration involves mapping from persistent grants the user keys, any extended attributes derived from the first stage, or both into OAuth access tokens.
When the authentication context matches specific mappings between the authentication sources, authentication policy contracts, or password credential validators, the attributes map into access tokens. include::ROOT:partial$pf_rc_authnmethodandprivatekeyjwtviahttprequestjavaobject.adoc[tags=pf_ph_authnMethodAndPrivateKeyJwtViaHttpRequestJavaObject] The HTTP Request Java object maps it into the access tokens.Data stores used here retrieve any required user attributes.
Runtime processing
At runtime, the first time a client requests an OAuth token, the process employs the two mapping sequences. Every time an existing persistent grant requests a new access token, the process invokes the second mapping.