PingAccess

Agent model

What is the agent model?

In the agent model, traffic is directed to the application, which has an agent plugin installed on the web server. The agent grants or denies access, and queries the PingAccess node when it requires additional information. The application in PingAccess is configured with the agent as the destination.

Pros

  • No network changes — Because the PingAccess agents are installed on the web servers, no network changes are required.

  • Minor performance improvements — In some cases, the agent can determine whether to grant access using cached data, which can reduce latency. In most cases, though, the agent must communicate with a PingAccess node, which results in latency similar to the gateway model.

Cons

  • Greater maintenance effort — You must maintain and upgrade agents independently on each web server.

  • Unavailable features — Some features can’t be used in an agent deployment. You can’t:

    • Rewrite the request URL

    • Rewrite response headers

    • Rewrite request or response body content

  • Cross-team coordination — Because the agents are installed directly on the web server, you might have to coordinate with other teams to install and maintain them.

  • Complex tracking — Keeping track of all agents can be difficult.

  • Difficult troubleshooting — Because the agent model involves more systems which can be varied in their OS and web server versions, troubleshooting issues can be more difficult.

  • Version dependencies — Because the agent must be installed as a plugin on the web server, there are dependencies on the web server and OS versions that aren’t present in the gateway model.

  • Less centralized logging — To view the logging for a specific transaction, you must review the agent audit log and the web server access logs.