Kong

API access control is a crucial aspect of ensuring the overall security of your APIs including the data and functionality they provide. Central to this is the need to be aware of the business context of the API usage, which includes the end-user on behalf of the request is made, and what function and data it is asked to provide.
For example, in a commercial banking application, this will mean making a decision based on the bank teller who's trying to access the bank account, which branch he is part of, what is his title, etc. And the actual bank account he is asking to access, the type or status of the account, and more.
The decision can’t be based just on the service account that is using that specific API. Though API Gateways do have access control capabilities, usually they are unaware of the context (i.e. will make a decision to determine if a call for a service can be made, and not based on the specific context of the call), and whatever identity-awareness they might have is limited and hard to manage.
Without contextual and identity-aware measures in place, there are significant risks associated with unauthorized access to the data through APIs.
PlainID Authorizer for Kong API gateways provides the API gateway with context awareness, of the identity and the assets the identity is trying to access.

The PlainID Kong Authorizer runs as a sidecar next to each instance of Kong. It can be deployed as a sidecar container within the Pod, or run as a service. When a request hits the Kong proxy, it queries the PlainID sidecar directly for an authorization decision. PlainID delivers the Authorization decision based on the policies configured in the Policy Administration Point (PAP).
The PlainID Kong Authorizer can provide two types of responses:
1. Permit / Deny - allow to or block the request as-is
2. Token Exchange and Token Enrichment - Enrich access token by injecting authorization claims into the request header, or mint a new access token containing only relevant information for the transaction

1. The end user accesses the application.
2. The user is redirected to complete the authentication process on the Identity Provider (IdP).
3. The API call is intercepted by Kong API GW.
4. The PlainID Authorizer requests an access decision from the PlainID PDP which responds with a dynamically calculated access decision based on the policies configured within the PlainID Authorization Platform. Access Decisions is enforced at the API GW. Request can be denied, permitted as-is, or permitted with PlainID enriching the access token with further Authorization instructions.
5. The API call is passed on to the service layer