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 an 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 the relationship between the PingAccess engine and the agents. One PingAccess engine can create multiple agent configurations, and each configuration can be used to create multiple PingAccess 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.