PingAccess can inject user attributes into requests only if those attributes are present in the OIDC/JWT presented by the IdP.

1) The IdP (token provider) therefore must be configured to add the required claims to the ID token (A).

2) After the claims exist, the PingAccess administrator must modify the Identity Mapping to pull the new claims from the ID token and place them into HTTP headers, cookies, or query parameters forwarded to the protected web application (B).

No changes to the Site Authenticator, Web Session, or access token are needed for attribute-injection in a browser-based OIDC-protected application.

C. Site Authenticator only governs how PingAccess sends credentials to the target site; it does not expose additional user attributes.

D. PingAccess injects attributes from the ID token, not the access token, for web applications; changing the access token would have no effect.

E. Web Session controls token caching/lifetime, not which attributes become available or forwarded.

1. Ping Identity, “PingAccess Administration Guide 2023 R1,” Section “Identity Mapping,” pp. 64-67: “PingAccess can map ID token claims to headers… ensure the IdP includes the required claims.”

2. Ping Identity, “PingFederate Server Guide 11.3,” Chap. 15 “OIDC Token Attribute Contract,” p. 454: “Add attributes to the ID token so relying parties can consume them.”

3. Ping Identity, “PingAccess OIDC Integration Overview,” v1.2, §3.2 “ID Token Claims as Attributes,” p. 10.