Building software as a service (SaaS) applications often comes with a challenge: How do you help ensure that only authorized users have access to the required resources? This challenge is daunting enough during early development, but after an application is already built and new features need to be added, the problem can be even more challenging to solve. The AWS Classroom team, which focuses on hands-on training for AWS customers and partners, recently faced this very issue and found a solution in Amazon Verified Permissions.
The Classroom team had built an application that allowed customers to manage hands-on learning environments through a dedicated user interface (UI). Customers were also doing manual scheduling activities on other internal applications. For example, they would list training sessions on learning management system (LMS) platforms and manage instructors’ assignments. These manual tasks had to be done in every system independently. To decrease manual process overhead for customers and unlock new pathways for automation, the Classroom team decided to build an API to allow external systems to manage learning environments. The initial customers of the Classroom’s API layer would be scheduling teams who could use the API to build automation making it necessary to only update manually in one system.
Figure 1: Existing workflow with proposed changes
It was important for the Classroom team to future-proof their solution by grouping resources, accessible through the new API, and assigning granular permissions to those resources. This approach provides an extensible mechanism to support future requirements and features.
The Classroom team needed to provide the scheduling teams with capabilities that would allow them to perform activities such as assigning instructors and locations, and have those updated in the Classroom system, via the new API. However, the developers needed to limit access to only the resources and actions required by a given scheduling team, thereby enforcing the principle of least privilege. The Classroom team chose to implement an approach where resources would be put into namespaces. At a minimum they would need two namespaces:
AWS Builder Labs: The original namespace. A UI and platform for configuring Classroom instances. Internal and external training coordinators use AWS Builder Labs to create classrooms manually for the training activities they support.
AWS Class Manager: The new namespace for scheduling activities. Class Manager has internal and external applications for scheduling instructor-led training sessions. This differs in scope from Builder Labs in that it focuses on allocation of instructors to training activities and alignment of scheduled activities.
Futurenamespaces with unknown specifications also needed to be supported. This meant the chosen solution needed to be scalable and flexible.
To support these requirements, the Classroom team needed a quick integration to enable logical resource separation because redesigning the entire app was not feasible with their time constraints. Many developers face such time constraints when focusing on delivering incremental market-competitive features, where re-implementing the application permission system is not an option.
The part Amazon Verified Permissions plays in the solution This is where Amazon Verified Permissions accelerated the solution. Amazon Verified Permissions is an AWS managed service that provides a scalable, authorization decision point for fine-grained authorization and permissions management. It uses the open-source Cedar policy language. Cedar is a language for expressing permissions as policies, which describe who should have access to what. It is also a specification for evaluating those policies. Cedar policies control what each user of your application is permitted to do and what resources they may access. These inputs and the policies written in Cedar specify the:
· Principal: who or what is trying to do something.
· Action: what they are trying to do.
· Resource: what they are trying to do it to.
The following code example for a photo sharing app shows a policy where any principal that belongs to a group called viewers can perform the view Action and comment on any resource in an album called photos.
These three components allow a developer or security expert the ability to define policies about how authorization should behave. For each user action, the application checks with Verified Permissions to determine if the action is authorized. This allows a developer to focus on the core logic of the application rather than building an entire authorization engine.
Building the API layer for the solution
Integrating an authorization engine allowed the Classroom team to focus on building their API and offload the authorization decisions to a service. To build the new API, the team chose AWS AppSync, a managed GraphQL service. The API actions would be performed by a combination of AWS Lambda and AWS Step Functions. Lambda also handles the integration to Verified Permissions. When an API call is submitted, a Lambda function checks to see if the current user should have access to the specific action and resource referenced in the API call, as shown in the following architecture diagram.
Figure 2: New architecture diagram for API layer
The preceding diagram illustrates the new approach. When a requestor from the AWS Class Manager group issues an API call, it provides context for that call including who is making the call (principal), what they are trying to do (action), and to what the action applies (resources). This information is then passed to Verified Permissions to see if a policy exists that will allow the action given the context. These policies are all authored in the Cedar policy language.
Designing the solution’s Cedar policies
The Cedar policies used to designate permissions for Builder Labs (the first namespace) were designed to allow for actions such as CreateClassroom, GetClassroom, UpdateClassroom, and CancelClassroom. To facilitate the new approach, resources were prefixed with a namespace to identify which resources were for the Builder Labs namespace, the Class Manager namespace, and any other future namespaces that might be required. For example, the resource of a policy would look like the following example where a namespace is listed for a classroom:
The Cedar policies the Classroom team built followed this same logic. The team retained access to all actions for all classes, but scheduling teams were able to perform these actions on resources only if their namespace was assigned to the class. To make this as flexible as possible while still maintaining simplicity of integration, the team used Verified Permissions policy templates. Each time a new record is created in the application, a policy is added using the template, which allows the team to maintain a consistent experience. The template the Classroom team built looks like the following:
When a policy is created for a new resource, the ?principal and ?resource are replaced by the actual principal and resource names that are applicable to the policy. In the following example policy, if a principal (in this case the account) is allowed to CreateClassroom (action) when it is doing so in a specific namespace (resource).
Summary
By integrating with Verified Permissions, the Classroom team was able to achieve several key benefits:
Faster development time: By integrating a prebuilt managed service to handle authorization, the Classroom team was able to focus on building the new API. The team spent approximately one month to develop the solution with Verified Permissions. Without Verified Permissions, it would have taken at least three months.
Improved security and access control: The Cedar policy language allowed the Classroom team to write the policies that enable fine grained access control in their app in a way that is both human readable and auditable.
Scalability and flexibility: As new feature requests come to the team in the future, the team can easily add Cedar policies to control access. They also have the scalability they need with Verified Permissions to support many more users and namespaces, if needed.
Centralized authorization management: By having a centralized decision point, the team can use a simplified architecture that allows them to quickly adjust and evolve policies over time.
The Classroom team will continue to use Verified Permissions to support new actions because of the ease of adding additional polices to their APIs. This use case highlights that it’s possible to build well-architected and fine-grained access controls into an application while still keeping the primary focus on building core features for end users.
Authors:
Dan Shallenberger Senior Solutions Architect Amazon Web Services
Gregg Dunn Senior SDE Amazon Web Services
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.
