Note:

Download the PingAccess agent for NGINX on the PingAccess Downloads page.

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

When a PingAccess agent is added to the policy decision process:

  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 showing the relationship between the PingAccess engine and PingAccess agent nodes.

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.