How to build a unified authorization layer for identity providers with Amazon Verified Permissions

3 minute read
Content level: Advanced
0

This article explains how to build a unified authorization layer for multiple identity providers using Amazon Verified Permissions.

Introduction

Enterprises often have an identity provider (IdP) for their employees and another for their customers. Using multiple IdPs allows you to apply different access controls and policies for employees and for customers. However, managing multiple identity systems can be complex. A unified authorization layer can ease administration by centralizing access policies for APIs regardless of the user’s IdP. The authorization layer evaluates access tokens from any authorized IdP before allowing API access. This removes authorization logic from the APIs and simplifies specifying organization-wide policies. Potential drawbacks include additional complexity in the authorization layer. However, simplifying the management of policies reduces cost of ownership and the likelihood of errors.

In this community article, we show you an architecture that demonstrates how to build a unified authorization layer using multiple Amazon Cognito user pools, Amazon Verified Permissions, and an AWS Lambda authorizer for Amazon API Gateway-backed APIs.

Architecture overview

This sample architecture relies on user-pool multi-tenancy for user authentication. It uses Cognito user pools to assign authenticated users a set of temporary and least-privilege credentials for application access. Once users are authenticated, they are authorized to access backend functions via a Lambda Authorizer function. This function interfaces with Verified Permissions to apply the appropriate access policy based on user attributes.

This sample architecture is based on the scenario of an application that has two sets of users: an internal set of users, veterinarians, as well as an external set of users, clients, with each group having specific access to the API.

Figure 1 shows the user request flow.

Enter image description here

Let’s go through the request flow to understand what happens at each step, as shown in Figure 1:

1. There two groups of users — External (Clients) and Internal (Veterinarians). These user groups sign in through a web portal that authenticates against an IdP (Amazon Cognito).
2. The groups attempt to access the get appointment API through API Gateway, along with their JWT tokens with claims and client ID.
3. The Lambda authorizer validates the claims.

** Note:** If Cognito is the IdP, then Verified Permissions can authorize the user from their JWT directly with the IsAuthorizedWithToken API.

4. After validating the JWT token, the Lambda authorizer makes a query to Verified Permissions with associated policy information to check the request.
5. API Gateway evaluates the policy that the Lambda authorizer returned, to allow or deny access to the resource.
6. If allowed, API Gateway accesses the resource. If denied, API Gateway returns a 403 Forbidden error.

** Note:** To further optimize the Lambda authorizer, the authorization decision can be cached or disabled, depending on your needs. By enabling caching, you can improve the performance, because the authorization policy will be returned from the cache whenever there is a cache key match. To learn more, see Configure a Lambda authorizer using the API Gateway console.

For the complete working solution and full walkthrough, refer to the AWS Blog here and our GitHub Repository.