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
Since 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 will result in latency similar to the gateway model.
Cons
- Greater maintenance effort
The agents must be maintained and upgraded independently on each web server.
- Unavailable features
Some features cannot be used in an agent deployment. You cannot:
- Rewrite the request URL
- Rewrite response headers
- Rewrite request or response body content
- Cross-team coordination
Since 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
Since 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
Since the agent must be installed as a plugin on the web server, there are dependencies on the web server and operating system versions that are not 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.