Flowchart overview of the process used when a PingAccess agent is added to the policy decision process.

The process used when a PingAccess agent is added to the policy decision process is as follows:

  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 signs on, 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 of the relationship between the engine and agents. One engine can create multiple agent configurations, which can each create multiple Agents.
Tip:

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

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