Kong API Gateway Authorization

Securing APIs in cloud native environments is not an easy task. Kong makes this easier by providing security features and plugins for enabling an API Defense In Depth approach for helping to provide enterprise grade security. SGNL extends an API defense in depth approach with continuous access management to the Kong API Gateway with a new LUA access plugin for the Kong API Gateway.

What is the Kong API Gateway

The Kong API Gateway is a highly flexible, robust, and extensible enterprise grade API gateway. Kong’s ability to run in a cloud native environment is exceptional, and Kong’s plugin hub offers a variety of enterprise grade plugins that extend the power of this fast gateway. You can see a list of authentication plugins here and a list of more general security plugins here.

This post will show you how to implement a SGNL Kong API Gateway plugin for managing and enforcing access to protected APIs. You can also combine this capability with the Continuous Access Evaluation Profile (CAEP) for processing event signals such as session revocation and credential changes implementing a real-time layered security approach.

Continuous Access Management

Continuous access management is the combination of methods, technologies, and business processes used to manage access to applications, infrastructure, or data. Continuous Access Management uses a dynamic and real-time authorization check for every request made by a user, device, or application to a resource provider (e.g., Application, Microservice, Database).

What is API Defense In Depth

As seen in the diagram below, API defense in depth consists of three main request layers that play a critical role in providing a comprehensive defense strategy against API attacks. Layer one involves authentication/coarse grained authorization and standard protocol usage, layer 2 is the API Gateway (i.e. Kong API Gateway), and layer three is the continuous access management platform (SGNL). In many cases, the identity provider (IDP) provides the user’s identity and profile information for the incoming request. The Kong API Gateway is a crucial part for orchestrating and securing the request, and SGNL provides the continuous access evaluation and management.

API Defense in Depth

This post focuses on layer 2 (API Gateway) and layer 3 (Continuous Access Management).

Continuous Access Evaluation

Continuous access evaluation (CAE) is a sub-capability of continuous access management. CAE is the ability to provide an authorization decision for every request, that may also include session events and changes communicated by using the Continuous Access Evaluation Profile (CAEP). See this post by our CTO Atul Tulshibagwale for an overview of CAEP. If you are looking for OIDC capabilities for your Kong API Gateway, you may try the Kong Auth0 plugin.

Here are three main reasons for extending your Kong API Gateway with continuous access evaluation and management, provided by a continuous access evaluation plugin:

• Enhance gateway authorization decisions with external business data - Using data generated by business processes, identity and security teams can ensure access to protected APIs is enforced by combining the real-time incoming request context and dynamic sourced from business systems such as Workday, Servicenow, Jira, PagerDuty, and Salesforce.
• Easily extend the gateway’s access stage with real-time business context for every request - Using the gateway’s access plugin stage, you can stop the request flow based on authorization decisions made by the external SGNL access service using the incoming request and associated normalized business data contained in the SGNL Graph Directory. This normalized business data represents a user’s relationship to business assets and processes across the enterprise.
• Simplification of policy management and centralized access audit - SGNL simplifies the creation, management, and auditability through the entire access policy lifecycle. By using the SGNL policy builder, an access administrator can pick and choose reusable policy snippets that can be used across applications and systems. See the sample human-readable policy in the How Does SGNL Work section.

With SGNL, you can enhance your Kong API Gateway with continuous access evaluation and management for your protected APIs and provide auditable, consistent, and fine-grained authorization decisions for every request.

Solution Approach

The solution consists of the Kong API Gateway (running in Kubernetes), sample Kong echo service, and the SGNL Kong API Gateway plugin implemented in LUA. The SGNL plugin runs “in-process” in the gateway itself, providing the optimal performance for every authorization request.

The gateway instantiates this plugin’s access function during the access stage of the request. The access function in the plugin then calls the SGNL Access Service and receives an “Allow” or “Deny” in the response. If the request is denied, the plugin then calls the exit function kong_response.exit(403, “SGNL Unauthorized”). This function interrupts the current gateway processing and produces a request flow interrupt response with an appropriate message.

This method produces a response before the Kong API gateway proxies the request to a backend service, which is a great way to stop a request if there are authentication issues or the request is not authorized by the SGNL plugin.

Logical Diagram Of Solution

The SGNL Platform

SGNL continuously ingests data from systems of record to a central graph directory via resilient and performant data ingest adapters. This data includes identity data, such as users and groups, and any relevant data required to define access policies, such as CMDB, ITSM cases, tickets from JIRA, incident status from PagerDuty, or customers from a CRM (e.g. Salesforce).

Applications or protected systems (i.e. API gateways, application servers, web servers) make authorization calls via control points (a.k.a policy enforcement points) to the SGNL policy engine. The policy engine calculates an authorization decision (Allow or Deny) and returns the decision to the control point or application. The SGNL Kong API Gateway plugin would be considered a control point or protected system.

Example SGNL Policy

In this post, we use Auth0 as the identity provider and user system of record. PagerDuty is the incident response and management platform. The open incident to user/responder assignment dictates whether or not a user is authorized to access the sample Kong echo service deployed in a Kubernetes cluster.

Once the system of record data sources (Auth0 and PagerDuty) are set up, administrators can quickly author and manage human-readable policies based on the ingested data for granting or denying access to Kong protected APIs.

An example of a real human-readable policy for demonstrating the custom authentication extension

Request Flow

Below is a sequence diagram describing the request flow from the API client through the Kong API Gateway, SGNL plugin, and finally back to the API client.

1. Request is sent from the HTTP(s) API client to the Kong API Gateway requesting the sample /echo service.
2. The SGNL Kong API Gateway plugin is instantiated by the gateway, and an authorization request/query is sent to the SGNL Access Service.
3. (A) If the authorization decision is “Allow”, the access service returns an allow authorization response to the SGNL plugin. (B) If the authorization decision “Deny”, the access service returns a deny response back to the SGNL plugin.
4. (A) If the SGNL plugin receives an “Allow” it lets the request flow smoothly and the Kong API Gateway continues its normal processing and sends the request to the upstream /echo service. (B) If the SGNL plugin receives a “Deny”, it then calls the exit function to interrupt the normal request flow and instructs the Kong API Gateway to return a 403 status code along with a custom “unauthorized” message back to the API client.
5. If the access is allowed, the upstream /echo service returns its response back to the Kong API Gateway, which is then sent to the API client in step 6.
6. The Kong API Gateway sends a response back to the API client.

Plugin Sample Code

The following code snippet is an example implementation of a Kong Plugin for calling the SGNL access service API.

You can download the full LUA source from the SGNL examples repository.

Code Snippet from The Kong Plugin

---

This plugin is an access plugin that calls the SGNL Access Service
for making authorization decisions. The handler is based on the OpenResty handlers, please refer to the OpenResty
documentation for more details.

---

local kong_response = kong.response
local http = require "resty.http"
local jsonparser = require "cjson"

local plugin = {
   PRIORITY = 1000, -- Plugin priority, which determines plugin execution order.
   VERSION = "0.1", -- Plugin version in X.Y.Z format. Check hybrid-mode compatibility requirements.
}

-- This function handles more initialization, but AFTER the worker process has been forked/created.

function plugin:init_worker()
   -- Say hello!
   kong.log.info("Hello 'SGNL plugin init_worker' handler")
end --]]

-- This function runs in the 'access_by_lua_block'

function plugin:access(plugin_conf)
   local cjson2 = jsonparser.new()
   local client = http.new()

   -- Get request headers for any request context needed.
   local headers = kong.request.get_headers()

   -- Build the JSON document for the request to the SGNL Access Service API.

   local json_text = '{"principal":{"id": "'..headers.principal..'"},"queries":[{"assetId":"'..kong.request.get_path()..'" ,"action":"'..kong.request.get_method()..'"}]}'

   -- Set the HTTP client timeouts.
   client:set_timeouts(10000, 60000, 60000)

   -- Configure HTTP client and make the request to the SGNL Access Service API.

   local res, err = client:request_uri("https://access.sgnlapis.cloud", {
      method = "POST",
      path = "/access/v2/evaluations",
      headers = {
         ["Authorization"] = "Bearer {SGNL bearer token.}",
         ["Content-Type"] = "application/json"
      },
      body = json_text
   })

   if not res then
      ngx.ERR(ngx.NOTICE, "Request to SGNL failed: ",err)
      return
   end

   -- JSON decode resopnse body, encode decisions, and decode once more to build a JSON object.

   local jdata = jsonparser.decode(res.body)
   local decisions = jsonparser.encode(jdata.decisions)
   local jsondecisions = jsonparser.decode (decisions)

   -- Check the first element in the decisions array. If more than one decision, you can iterate through array and check all decisions.

   -- This example only returns one decision at index 1. Note: LUA array indexes start at 1.

   if jsondecisions[1].decision ~= 'Allow' then
      return kong_response.exit(403, "SGNL Unauthorized")
   end
end --]]

-- This function runs in the 'header_filter_by_lua_block'.
function plugin:header_filter(plugin_conf)

   -- Send back a sample header with a message so the client knows the SGNL plugin is enabled.
   kong.response.set_header(plugin_conf.response_header, "SGNL authorization plugin is enabled.")
end --]]

-- Return the plugin object.
return plugin

Configuration

For steps to install, test, and configure the Kong API Gateway plugin visit the SGNL examples Git repo’s readme file.

Conclusion

SGNL enables API Defense in Depth for Kong and other API Gateways. Using SGNL for managing access to your Kong API Gateway protected APIs, especially high-risk APIs - organizations can reduce risk, security administrators can minimize authorization logic complexity, and teams can centralize access management policy in a single platform for making complex, consistent, and continuous authorization decisions.

Schedule time with a SGNLer to see how all this can work in your context.