Diagram showing the process used when a PingAccess agent is added to the policy decision process.

Processing steps

  1. The client accesses a resource. If the user is already authenticated, this process continues with step 5.
  2. The agent asks PingAccess for instructions. PingAccess checks the URL policy and determines that it is a protected resource. PingAccess then redirects the client to PingFederate to establish a session.
  3. The user logs in, and PingFederate creates the session.
  4. The client is then redirected back to the resource.
  5. The agent asks PingAccess for instructions. PingAccess checks the URL policy and determines that it is a protected resource. PingAccess then checks the session token and determines that it is valid.
  6. If session revocation is enabled, PingAccess checks and updates the central session revocation list. If the session is valid, the agent is instructed to set identity HTTP headers.

Within the PingAccess administrative console, agent nodes are configured with information that allows a PingAccess agent to connect to the engine node to retrieve information about access control policies for resources within that agent's control. An agent configuration has a one-to-many relationship with PingAccess agents, allowing a single agent configuration bootstrap file to be used on multiple web servers within a server farm.

Diagram showing how the PingAccess engine communicates with agents.
Note:

An agent node is a shared configuration used by one or more agents, rather than a specific agent instance.

Tip:

A problem with the PingAccess IIS agent configuration might cause all applications in an IIS application pool to become unreachable. To maximize availability of unprotected resources, place applications protected by the PingAccess agent in a separate pool.

The features documented here are affected by the settings in the configuration file. See the Configuration file reference for more information.