What is the sideband model?
In the sideband model, traffic is directed to an API gateway, such as Apigee or Mulesoft. The API gateway makes a back channel call to PingAccess to determine if it should grant or deny the request and determine what modifications should be made to the request or response. The application in PingAccess is configured with the sideband client as the destination.
Pros
- No network changes — Because the PingAccess sideband clients are installed on the API gateways, no network changes are required.
- Simpler troubleshooting — Issues are easier to isolate because 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
- Greater maintenance effort — The API gateway integration kits must be maintained and upgraded independently on each API gateway.
- Unavailable features — Some features may not be available depending on your API gateway.
- Additional network overhead — The overhead of an additional network hop can theoretically exceed a latency budget. This rarely happens in practice, and the gateway and agent models often make a similar addition to latency, but in some environments it might occur.
- Cross-team coordination — Because the sideband clients are installed directly on the API gateways, you might have to coordinate with other teams to install and maintain them.
- Complex tracking — A sideband deployment has more components to maintain than a gateway deployment.
- Version dependencies — Because the sideband client must be installed on the API gateway, there are dependencies on the API gateway and operating system versions that are not present in the gateway model.