The access request is transparent to the user, allowing PingAccess to transparently manage access to systems using those foreign tokens. The request is also transparent to the protected application, which handles the access request as if it came from the user directly. After token mediation has occurred, the token used for accessing the application is cached for continued use during the session.


When planning a PingAccess deployment, take inventory of existing applications and their authentication requirements and mechanisms. When an existing token-based authentication mechanism is in use, retrofitting that mechanism might not always be desirable or cost-effective.

The following illustration shows an example of token mediation using PingFederate to exchange a PingAccess token or OAuth bearer token for a different security token.

Diagram illustrating token mediation between PingFederate and PingAccess.

Processing steps:

  1. A user requests a resource from PingAccess with a PingAccess token or OAuth bearer token.

    This example assumes the user has already obtained a PingAccess token or OAuth bearer token. See the Session Management scenario for information on how users authenticate with PingFederate and obtain a PingAccess token or OAuth bearer token.

  2. PingAccess evaluates resource-level policies and performs token mediation by acquiring the appropriate security token from the PingFederate security token service (STS) specified by the site authenticator.
  3. PingAccess sends the request to the site (web application) with the appropriate token.
  4. PingAccess returns the response to the client (not shown).