Multi-tenant SaaS authorization and API access control: Implementation options and best practices - AWS Prescriptive Guidance

Multi-tenant SaaS authorization and API access control: Implementation options and best practices

Tabby Ward, Thomas Davis, Gideon Landeman, and Tomas Riha, Amazon Web Services (AWS)

May 2024 (document history)

Authorization and API access control are a challenge for many software applications—in particular, for multi-tenant software as a service (SaaS) applications. This complexity is evident when you consider the proliferation of microservice APIs that must be secured and the large number of access conditions that arise from different tenants, user characteristics, and application states. To address these issues effectively, a solution must enforce access control across the many APIs presented by microservices, Backend for Frontend (BFF) layers, and other components of a multi-tenant SaaS application. This approach must be accompanied by a mechanism that is capable of making complex access decisions based on many factors and attributes.

Traditionally, API access control and authorization were handled by custom logic in the application code. This approach was error prone and not secure, because developers who had access to this code could accidentally or deliberately change authorization logic, which could result in unauthorized access. Auditing the decisions made by custom logic in the application code was difficult, because auditors would have to immerse themselves in the custom logic to determine its effectiveness in upholding any particular standard. Furthermore, API access control was generally unnecessary, because there weren't as many APIs to secure. The paradigm shift in application design to favor microservices and service-oriented architectures has increased the number of APIs that must use a form of authorization and access control. In addition, the need to maintain tenant-based access in a multi-tenant SaaS application presents additional authorization challenges to preserve tenancy. The best practices outlined in this guide provide several benefits:

  • Authorization logic can be centralized and written in a high-level declarative language that is not specific to any programming language.

  • Authorization logic is abstracted from the application code and can be applied as a repeatable pattern to all APIs in an application.

  • The abstraction prevents accidental changes by developers to authorization logic.

  • Integration into a SaaS application is consistent and simple.

  • The abstraction prevents the need to write custom authorization logic for each API endpoint.

  • Audits are simplified, because an auditor no longer needs to review the code to determine permissions.

  • The approach outlined in this guide supports the use of multiple access control paradigms depending on the requirements of an organization.

  • This authorization and access control approach provides a simple and straightforward way to maintain tenant data isolation at the API layer in a SaaS application.

  • The best practices provide a consistent approach to onboarding and offboarding tenants with regard to authorization.

  • This approach offers different authorization deployment models (pooled or silo), which have both advantages and disadvantages, as discussed in this guide.

Targeted business outcomes

This prescriptive guidance describes repeatable design patterns for authorization and API access controls that can be implemented for multi-tenant SaaS applications. This guidance is intended for any team that develops applications with complex authorization requirements or strict API access control needs. The architecture details the creation of a policy decision point (PDP) or policy engine and the integration of policy enforcement points (PEP) in APIs. Two specific options for creating a PDP are discussed: using Amazon Verified Permissions with the Cedar SDK and using the Open Policy Agent (OPA) with the Rego policy language. The guide also discusses making access decisions based upon an attribute-based access control (ABAC) model or role-based access control (RBAC) model, or a combination of both models. We recommend that you use the design patterns and concepts provided in this guide to inform and standardize your implementation of authorization and API access control in multi-tenant SaaS applications. This guidance helps achieve the following business outcomes:

  • Standardized API authorization architecture for multi-tenant SaaS applications – This architecture distinguishes between three components: the policy administration point (PAP) where policies are stored and managed, the policy decision point (PDP) where those policies are evaluated to reach an authorization decision, and the policy enforcement point (PEP) that enforces that decision. The hosted authorization service, Verified Permissions, serves as both a PAP and a PDP. Alternatively, you can build your PDP yourself by using an open source engine such as Cedar or OPA.

  • Decoupling of authorization logic from applications – Authorization logic, when embedded in application code or implemented through an ad hoc enforcement mechanism, can be subject to accidental or malicious changes that cause unintentional cross-tenant data access or other security breaches. To help mitigate these possibilities, you can use a PAP, such as Verified Permissions, to store authorization policies independently of the application code, and to apply strong governance to the management of those policies. Policies can be maintained centrally in a high-level declarative language, which makes maintaining authorization logic far simpler than when you embed policies in multiple sections of application code. This approach also ensures that updates are applied consistently.

  • Flexible approach to access control models – Role-based access control (RBAC), attribute-based access control (ABAC), or a combination of both models are all valid approaches to access control. These models attempt to meet the authorization requirements for a business by using different approaches. This guide compares and contrasts these models to help you select a model that works for your organization. The guide also discusses how these models apply to different authorization policy languages, such as OPA/Rego and Cedar. The architectures discussed in this guide enable either or both models to be adopted successfully.

  • Strict API access control – This guide provides a method to secure APIs consistently and pervasively in an application with minimal effort. This is particularly valuable for service-oriented or microservice application architectures that generally use a large number of APIs to facilitate intra-application communications. Strict API access control helps increase the security of an application and makes it less vulnerable to attack or exploitation.

Tenant isolation and multi-tenant authorization

This guide refers to the concepts of tenant isolation and multi-tenant authorization. Tenant isolation refers to explicit mechanisms that you use in a SaaS system to ensure that each tenant's resources, even when they operate on shared infrastructure, are isolated. Multi-tenant authorization refers to authorizing inbound actions and preventing them from being implemented on the wrong tenant. A hypothetical user could be authenticated and authorized, and still access the resources of another tenant. Authentication and authorization won't block this access—you need to implement tenant isolation to achieve this objective. For a more extensive discussion of the differences between these two concepts, see the Tenant isolation section of the SaaS Architecture Fundamentals whitepaper.