Authorization for Protected APIs - The Patient Record API

In our previous blog we discussed securing APIs and ensuring you are protected for both authentication and authorization while keeping the request context intact. This sounds easy, but to successfully protect your APIs, the system must perform a series of checks, especially the introspection of an access token to retrieve the user’s identity needing authorization. In this post, we will demonstrate the technical solution involving SGNL, Curity, and the Kong API Gateway.

Use Case

This demonstration showcases access requests to a patient record. In healthcare organizations, it is common for patients to have access to their own patient records, but access should be restricted to view a different individual’s patient records. For example, if Alice attempts to access Bob’s patient data, she should be denied.

This demo implementation includes a sample patient records API which is protected by the Curity Identity Server, SGNL, and Kong. Curity authenticates the user and generates appropriate access tokens. The Kong gateway’s plugins intercept the request for the record data and orchestrates the validation of the identity in the request and enforces fine grained access through the SGNL Kong plugin.

Solution Approach

The security solution for the sample patient record data 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 by SGNL 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 Plugin - Provides the continuous access evaluation capabilities for every request by ensuring each request is authorized based on the authorization data stored in the incoming request and SGNL graph directory.
4. Patient Records API - This API is a sample patient record API that responds to a patient record request with sample patient data.

Logical Diagram Of Solution

Request Sequence

The following is the request sequence initiated by a user application.

1. Application authenticates the user with the Curity Identity Server. The Identity server issues ID and access tokens.
2. The user via the application requests to see patient records.
3. The Curity plugin introspects the token and generates a phantom token.
4. If the The SGNL Kong plugin is configured to introspect the token, it then introspects the token (using the Curity Identity Server) and extracts the subject in the access token. If the SGNL Kong Plugin is configured to simply load the phantom JWT, it extracts the subject from the JWT and continues to step five.
5. The SGNL Kong plugin makes an authorization request to the SGNL policy engine for the record id being requested.
6. The SGNL policy engine returns an “Allow” if access is granted or a “Deny” if access to the record is denied.
7. If the request is allowed by SGNL, the Kong gateway allows the request to go to the upstream patient records API.
8. The patient records API returns the record to the Kong Gateway.
9. The Kong Gateway then returns the allowed record (JSON) to the user application.

Policy

Every request for patient records is evaluated against a SGNL human readable policy. The policy below checks the incoming user’s access to their own patient records. The “Patient” snippet checks to see if it’s a valid user making the request. The “GET” represents the HTTP verb sent by the SGNL Kong plugin. The “Record” represents the protected patient record asset. This policy also includes a condition to check if the user is the owner of the record asset being requested.

GitHub

You may download the solution by cloning the examples repository. The solution files are under the curity-sgnl-kong directory. You may find environment setup instructions in the README.md file.

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.