In the gateway model, traffic is initially directed to a PingAccess node, and PingAccess grants or denies access directly. The application in PingAccess is configured with the site as the destination.
Pros
- Less cross-team coordination required
You can implement and maintain a gateway deployment with less coordination with application teams, since the PingAccess infrastructure is installed on separate systems from the web servers.
- Simpler setup
Since the PingAccess nodes are the only required components, this deployment model can be set up more quickly.
- Simpler upgrade
The only components that must be upgraded in a gateway deployment are the PingAccess nodes. PingAccess can be upgraded with zero downtime in a clustered environment.
- Simpler troubleshooting
Issues are easier to isolate since there are fewer components sharing a system with the PingAccess infrastructure.
- Simpler logging
All transactions processed by PingAccess are audited by the engine node, making it easier to view logs for a specific event.
Cons
- Network impact
It requires that you restructure your existing network to route traffic through PingAccess.
- Additional network overhead
The overhead of an additional network hop can theoretically exceed a latency budget. This rarely happens in practice, and the agent model often makes a similar addition to latency, but in some environments it may occur.