Application and data security are two challenges many enterprises face. At the core of any enterprise security solution are the challenges faced with managing its Authorization Policies. Essentially, WHO (Identity) can do WHAT (Action) with WHAT (Assets) and WHEN (under what environmental conditions).
The Platform enables you to create and manage fine-grained, flexible access policies that consider a user’s role and other parameters (task, time, membership in a dynamic group, role or title, place, etc.) under specific conditions occurring in real-time.
Enterprises are faced with determining both the policies related to Authorization and the method by which they can implement these policies. For many, a service mesh can be the transparent infrastructure layer that sits between a network and its microservices. This service mesh can be the ideal location where organizations can ensure data encryption, authentication, and authorization.
About Apigee
The Apigee platform enables you to develop and manage backend service APIs by offering a proxy layer through which Access Policies can be enforced across the organizational technological stack with minimal involvement from developers. The Apigee Authorizer, an API Gateway Authorizer, becomes a single point of contact, reducing dependency for changes at the developer level.
Apigee Workflow
In the Platform, you can manage access control Policies that answer the basic or the most advanced authorization question – WHO can access WHAT and WHEN.
For microservices this can translate as follows:
- Who? Based on the user characteristics of who is accessing the resource.
- What? Based on URLs, URL payload, headers, and associated actions.
- When? Based on environmental attributes, such as time, location, events and more.
Apigee Authorizer Workflow
The following is a typical workflow for the Apigee Authorizer and the Platform.
Use Example
Explanation
- The end user access the app.
- The user is redirected to complete the authentication process on the IdP.
- The API call is intercepted by the apigee API GW.
- Using a Flow Callout, the API proxy calls the PlainID Authorizer which is a Shared Flow that can serve multiple proxies.
- 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.
- The client can access API resources and services.
Mapping Between Access Policy and Authorization Request
Mapping between the access policy and the actual authorization request should be as follows:
| Access Policy | Request |
|---|---|
| WHO – Identity, for example: “Customer” | The Identity is derived from the JWT that is passed in the request header. The Platform can rely on the data provided in the JWT or enrich it with other sources of data to determine the user is a “Customer”. |
| WHAT – Action, for example: View Customer Accounts | View – can be mapped to the request action: “GET” or derived from the request body (in a POST request). Account – derived from the request URL suffix (in the example) or derived from the request body (in a POST request). |
| WHEN (Conditions) - MFA | The Environmental Conditions as authentication methods are derived from the request header.To support the above, the Platform defines structured elements to represent the WHO (the “subject”) and the WHAT (the “object”). |
Subject – is typically the user who is requesting access, defined by the Identity Template.
Object – is what the user is trying to access, defined by the Asset Template..
For additional information about API Mappers, check the Working with API Mappers page on the documentation portal.