This guide describes the deployment of PingIntelligence for APIs in a sideband configuration with NGINX Plus. A PingIntelligence sideband policy is installed in NGINX Plus and passes API metadata to PingIntelligence for detailed API activity reporting and attack detection with optional client blocking. PingIntelligence software adds support for reporting and attack detection based on usernames captured from token attributes.

Traffic flow for NGINX Plus integration without user information

Here is the traffic flow through NGINX and PingIntelligence for APIs components.

  1. Client sends an incoming request to NGINX
  2. NGINX makes an API call to send the request metadata to ASE
  3. ASE checks the request against a registered set of APIs and looks for the origin IP, cookie, OAuth2 token or API key in PingIntelligence AI engine generated Blacklist. If all checks pass, ASE returns a 200-OK response to the NGINX. If not, a different response code is sent to NGINX. The request information is also logged by ASE and sent to the AI Engine for processing.
  4. If NGINX receives a 200-OK response from ASE, then it forwards the request to the backend server. Otherwise, NGINX optionally blocks the client.
  5. The response from the backend server is received by NGINX.
  6. NGINX makes a second API call to pass the response information to ASE which sends the information to the AI engine for processing.
  7. ASE receives the response information and sends a 200-OK to NGINX.
  8. NGINX sends the response received from the backend server to the client.

Traffic flow for NGINX Plus integration with user information

Here is the traffic flow through the NGINX Plus and PingIntelligence for APIs components. PingFederate is used as the OAuth server to gather the user information:

  1. Client requests and receives an access token from PingFederate.
  2. Client sends a request with the access token received from PingFederate.
  3. NGINX Plus verifies the authenticity of the access token with PingFederate.
  4. If the request is invalid, ASE sends a 403 error and NGINX Plus drops the connection request.
  5. If the token is valid, the PingIntelligence policy running in NGINX Plus collects API metadata and token attributes. In case of an invalid token, the request is allowed, however, without user information.
  6. NGINX Plus makes an API call to send the request information to ASE. ASE checks the request against a registered set of APIs and checks the origin IP, cookie or OAuth2 token against the AI generated Blacklist. If all checks pass, ASE returns a 200-OK response to the NGINX Plus. If not, a different response code is sent to NGINX Plus. The request information is also logged by ASE and sent to the AI Engine for processing.
  7. If NGINX Plus receives a 200-OK response from ASE, then it forwards the request to the backend server. Otherwise, the Gateway optionally blocks the client.
  8. The response from the backend server is received by NGINX Plus. NGINX Plus sends the response received from the backend server to the client.
  9. NGINX Plus makes a second API call to pass the response information to ASE which sends the information to the AI engine for processing. ASE receives the response information and sends a 200-OK to NGINX Plus.
  10. NGINX Plus sends the response to the client.