PingAccess

How does PingAccess work?

Access requests are either routed through a PingAccess gateway to the target site or intercepted at the target web application server by a PingAccess agent, which coordinates access policy decisions with a PingAccess policy server.

In either instance, PingAccess evaluates the policies applied to access requests for the target application and makes a policy-based decision to grant or deny access to the requested resource. After access is granted, PingAccess can modify client requests and server responses to provide additional identity information required by the target application.

WAM session initiation

When a user authenticates, PingAccess applies your configured application and resource-level policies to the Web Access Management (WAM) request.

After completing policy evaluation and determining that the authenticated user should be granted access to a site, PingAccess performs any required token mediation between the backend site and the authenticated user. PingAccess then grants the user access to the site.

Diagram illustrating the WAM flow between and .
Processing steps:

  1. When a user requests access to a web resource from PingAccess, PingAccess inspects the request for a PingAccess token.

  2. If the PingAccess token is missing, PingAccess redirects the user to an OpenID Provider (OP) for authentication.

    When using an OP, you must already have an OAuth client configured in PingAccess.

  3. The OP follows the appropriate authentication process, evaluates domain-level policies, and issues an OIDC ID token to PingAccess.

  4. PingAccess validates the ID token and issues a PingAccess token and sends it to the browser in a cookie during a redirect to the original target resource.

    After gaining access to the resource, PingAccess evaluates application and resource-level policies and can optionally audit the request.

    PingAccess can perform token mediation by exchanging the PingAccess token for the appropriate security token from the PingFederate Security Token Service (STS) or from a cache if token mediation occurred recently.

  5. PingAccess forwards the request to the target site.

  6. PingAccess processes the response from the site to the browser (step not pictured).

For more information, see the Session management configuration.

Token mediation

Token mediation allows a PingAccess gateway to use a PingFederate token generator to exchange the PingAccess token or an OAuth bearer token for a security token used by the foreign authentication system.

When planning a PingAccess deployment, take an 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 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, PingAccess caches the token used to access the application for continued use during the session.

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 and .
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. For information on how users authenticate with PingFederate and obtain a PingAccess token or OAuth bearer token, see Session management configuration.

  2. PingAccess evaluates resource-level policies and performs token mediation by acquiring the appropriate security token from the PingFederate 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 (step not pictured).

    You can’t access a mediated token through a Groovy rule because token mediation occurs after PingAccess rule processing.
Token mediation cache settings

You can configure token mediation cache settings in the run.properties file using the following parameters:

pa.ehcache.ServiceTokenCache.maxEntriesLocalHeap

Defines the maximum number of entries in the local heap for token mediation. The default value is 10000.

pa.ehcache.ServiceTokenCache.timeToIdleSeconds

Defines, in seconds, the time an entry in the token mediation cache can be idle before it is expired. The default value is 1800.

pa.ehcache.ServiceTokenCache.timeToLiveSeconds

Defines, in seconds, the maximum time an entry can be in the token mediation cache. The default value is 14400.