Envoy API Gateway

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 Envoy API gateways provides the API gateway with context awareness, of the identity and the assets the identity is trying to access.

The PlainID Envoy Authorizer runs as a sidecar next to each instance of Envoy. It can be deployed as a sidecar container within the Pod, or run as a service. When a request hits the Envoy 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 Envoy 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 client sends its access/ID token in the request header.
2. The request is intercepted by the Envoy Proxy and passed to the PlainID Sidecar container. The PlainID sidecar container is automatically injected into the pods through configuration settings within Envoy.
3. The PlainID sidecar container 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. The decision can be on the request URL, request header, and request body.
4. In case the authorization decision is Permit, the Envoy proxy passes the request to the service container as-is or Enrich the request header with entitlements or additional information to provide specific access data to the service. Otherwise, If the authorization decision is denied, the request never reaches the actual service container and a 403 response is returned immediately.