Authorization for Curity protected APIs

Securing APIs and ensuring you are protected for both authentication and authorization while keeping the request context intact can be a challenge. In this post, we will see how to leverage SGNL, Curity, and the Kong API Gateway so you can rest assured your APIs are well protected.

Who is Curity

Curity is a leading provider of IAM and API security technology that enables user authentication and authorization for a wide range of digital services. The Curity Identity Server is highly scalable, and handles the complexities of the leading identity standards, making them easier to use, customize and deploy.

What is the Curity Identity Server

The Curity Identity Server is a standards-based (OAuth2/OIDC) authentication identity provider for protecting both applications and APIs. A principal is authenticated by the server using authentication flows. The results are issued tokens that contain preconfigured claims and scopes. These tokens are then used to access protected applications and APIs. The applications and APIs then validate the tokens with the Curity Identity Server to ensure security and access control.

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. For more information on the SGNL plugin for the Kong API Gateway, visit this post. To see the implementation for the Curity Phantom token plugin, see the source here.

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 (the Curity Identity Server) 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 this post, the identity provider (the Curity Identity Server) provides the user’s identity and claim information for the incoming request. The Kong API Gateway orchestrates the request after validating authentication, and SGNL provides the continuous access evaluation and management.

API Defense in Depth

This post focuses on layer 1 (the Curity Identity Server), layer 2 (Kong API Gateway), and layer 3 (SGNL).

Why Better Together Makes Sense

In my experience in this industry, I have learned that not any one point solution can fully stand on its own. An API defense in depth strategy is all encompassing and requires different solution sets to work together for the optimal protection against attackers.

Here are three main reasons for joining the three key layers of the API defense in depth approach:

• Enhance Identity Provider and API 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 authorization data sourced from business systems such as Workday, Servicenow, Jira, PagerDuty, and Salesforce.
• Make advanced authorization decisions with real-time business context for every request - Using the Identity Provider’s (Curity) claims, the Kong OIDC plugin and the gateway’s access stage plugin from SGNL, you can stop the request flow to the upstream service based on authorization decisions made by the SGNL access service. By using the Identity Provider claims data in the request and associated normalized authorization data contained in the SGNL Graph Directory, you can choose to allow access at the API endpoint, API object, or field levels.
• 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.

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

Solution Approach

The solution is comprised of three main components:

1. The Curity Identity Server - This is the identity provider that authenticates the principal and issues access and identity tokens. Tokens hold/transport asserted claim data that are later used to make fine-grained authorization decisions.
2. Kong API Gateway - This is the gateway that validates the access and identity tokens before sending the request upstream.
3. SGNL - Provides the continuous access evaluation capabilities for every request by ensuring each request is authorized based on the authorization data stored in the SGNL graph directory.

The API client makes an authentication request on behalf of the user to the Curity Identity Server. The Curity Identity Server authenticates the principal and issues an access and identity token. The access token is sent by the API client to the upstream API service which is proxied by the Kong API Gateway. Before the gateway can proxy the request, SGNL validates the bearer token generated by the Curity Identity Server and checks to see whether the principal is allowed to access the API resources based on advanced authorization policy. If SGNL responds with an “Allow” the request is sent to the upstream service by the Kong API Gateway. If SGNL responds with “Deny”, the Kong API Gateway halts the request and returns a 403 forbidden message to the API client.

Logical Diagram Of Solution

Stay tuned for our next Curity, Kong, and SGNL blog post that will show exactly how this pattern is implemented.

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.

Conclusion

SGNL and Curity enable API defense in depth for APIs. Using SGNL for managing access to your Curity and Kong API Gateway protected APIs, especially high-risk APIs - organizations can reduce risk, minimize authorization logic complexity, and teams can centralize access management policy in a single platform.

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