Apigee

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

1. The end user access the app.
2. The user is redirected to complete the authentication process on the IdP.
3. The API call is intercepted by the apigee API GW.
4. Using a Flow Callout, the API proxy calls the PlainID Authorizer which is a Shared Flow that can serve multiple proxies.
5. 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.
6. 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.
7. 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:

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.