Azure API Management

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

The PlainID Azure API Management Authorizer utilizes Azure's Inbound Processing Policy.
The PlainID Azure API Management 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 Azure API Management.
4. The PlainID Authorizer receives requests and queries the PDP for dynamically calculated access decisions based on configured policies. These decisions are enforced at the API Gateway, either denying, permitting as-is, or permitting with enriched access tokens containing additional authorization instructions.
5. The API call is passed on to the service layer