Integration with Kong Gateway allows PingAuthorize to handle the complexities of attribute-based access control and dynamic authorization, making it easier for you to control access to your API resources. Instead of configuring policies multiple times, deploy the Kong Gateway integration once and manage your policy rules in PingAuthorize.

The following diagram explains how traffic flows through Kong Gateway and PingAuthorize.

Workflow diagram illustrating the API request-and-response flow between the HTTP client, Kong Gateway, PingAuthorize, and the resource server.
  1. The HTTP client sends an inbound request to Kong Gateway.
  2. Kong Gateway sends a sideband request to PingAuthorize.
  3. PingAuthorize Server evaluates the request against policies defined in the PingAuthorize Policy Editor and sends a permit or deny response to Kong Gateway.
  4. Kong Gateway analyzes the response from PingAuthorize to determine whether the request should be allowed to the resource server—and if so, whether there should be any modification to the request. Should the request be denied, then PingAuthorize includes directives to influence how Kong Gateway responds to the HTTP client.
  5. If the request is permitted, the resource server sends an outbound response to Kong Gateway.
  6. Kong Gateway passes the response to PingAuthorize for processing.
  7. PingAuthorize sends a response to Kong Gateway.
  8. Kong Gateway processes the response from PingAuthorize. This includes directives for how to modify the response to the HTTP client, if any modifications should be made.
Note:

The following notes are important to consider when using the ping-auth Kong Gateway integration plugin for PingAuthorize:

Mutual TLS (mTLS)
This plugin supports client certificate authentication using mTLS; however this feature requires using the mtls-auth plugin (only available in the enterprise edition of Kong) in conjunction with ping-auth. For more information, see the Kong mTLS documentation. When configured, mtls-auth uses the mTLS process to retrieve the client certificate, which allows ping-auth to provide the certificate in the client_certificate field of the sideband requests.
Transfer-Encoding
Because of an outstanding defect in Kong, ping-auth is unable to support the Transfer-Encoding header, regardless of the value.
Logging limit
Because of OpenResty's log level limit, log messages are limited to 2048 bytes by default, which is less than the size of many requests and responses. For more information, see the OpenResty reference documentation.