PingAuthorize

For further consideration: The PingAuthorize API security gateway, part 2

Additional concepts to consider include the phases of API security gateway processing and the need for the service name to match the Gateway API Endpoint name.

API security gateway processing occurs in two phases

The inbound phase

When the API security gateway receives an HTTP request, it generates a policy request with an action label including the phase and the HTTP method, such as inbound-POST or inbound-GET. Based on the result returned by the policy engine, the request might be rejected immediately or it might be forwarded to the API server, potentially with modifications.

The following diagram illustrates the inbound request processing.

Diagram of inbound request from the HTTP client to the API gateway, to the policy engine, which sends a policy decision to the gateway, which forwards a response to the API

The outbound phase

When the API server returns an HTTP response to the API security gateway, another policy request is generated, again with an action label including the phase and HTTP method, such as outbound-POST or outbound-GET. Based on the result returned by the policy engine, the response might be modified, and then it is forwarded back to the HTTP client.

The following diagram illustrates the outbound request processing.

Diagram of outbound request from the API to the API gateway, to the policy engine, which sends a decision back to the gateway, which forwards a response to the HTTP client

Service name must match Gateway API Endpoint name

In Adding a policy for the Create Game endpoint, we named the service to match the name of the Gateway API Endpoint in the PingAuthorize configuration. This is important. When PingAuthorize receives an HTTP request, it generates a policy request that represents the HTTP request and sends it to its policy engine for processing. The policy request will include a service field, and its name will be the name of the Gateway API Endpoint that handled the HTTP request.