Multi-Tenant SaaS Identity and Access Control Management

SaaS platforms have different customers/subscribers, or, “tenant” users, in technical terms. For B2B SaaS such tenants are often organizations. If the SaaS platform is deployed in the cloud using multitenant architecture for cost-effectiveness, the platform’s customers use the same databases and storages as others. SaaS platform owners have to prevent user access from one customer to another customer's private information. The solution is the implementation of multi-tenant SaaS identity and access control management.

When thinking about solutions to manage, authenticate, and authorize their users, SaaS owners with the help of SaaS developers have to make architecture design choices. The right design depends on what customers of SaaS platforms need.

Using a centralized identity provider and implementing role-based access control seems today the most common, however not exclusive, scenario for identity and access control management.

Centralization

The approach to implementing the identification and access control by the code in multiple sections within the application is insecure and considered legacy because the app developers can make accidental changes to it. A possible security breach is cross-tenant data access.

The modern approach focuses on offloading the authentification/authorization logic to a separate centralized system from the application code. It increases the security of a SaaS application and makes it less vulnerable to attacks or exploitations. Additionally, centralization helps escape the need to write repetitive code each time.

Role-Based Access Control

Role-based access control is an authorization system that determines access to resources based on a user’s role. It’s a simple access control model to implement because it aligns well with easily recognizable business logic.

In such a design, administration permissions can be provided to any level of the group hierarchy. visual-guard.com

Example of the Role-Based Access Control for a Hospitality SaaS Solution to protect cloud tenants’ privacy and improve the efficiency of cloud management. This model works well with large-scale users and can cope with the surge of user numbers within limited cloud resources.

Example of SaaS Identity and Access Control Management using Azure Active Directory 

The Challenge of Multi-Tenant SaaS Identity and Access Control Management and its Solution

Let's say you're writing an enterprise multi-tenant cloud-based SaaS application. 

The application has two users alice@contoso and bob@fabricam which belong to different organizations.

When Alice signs in, the application has to know that Alice employee is part of Contoso Customer and should have access to Contoso Customer data but shouldn't have access to Fabrikam Customer data. 

Moreover, each SaaS customer should have the ability to assign the roles like "Admin" or "Standard User" themselves without asking the help from you as the SaaS provider

The properly configured processes of verifying the identity of users (Authentication) and controlling their access to resources and actions (Authorization) are solutions to the above-described challenge. 

microsoft.com

After implementing Azure AD, the flow looks like this:

1. Authentication. Alice from Contoso uses the browser to navigate to the SaaS application and press the "Log in" button. She's redirected to a sign-in screen where she enters her corporate credentials (for example, username and password). She's logged into the app.
2. Authorization. The multi-tenant SaaS application knows that Alice is an admin user for this application and can use the resources that belong to Contoso. However, she can't view Fabrikam's resources, because she's an admin only within her tenant.

Architecture for Tenant Authentication

Let's say such a multitenant SaaS application consists of a web front-end and a web API backend implemented using ASP.NET Core, which has built-in middleware for the OpenID Connect protocol. 

microsoft.com

microsoft.com

The SaaS web application: 

• uses the OpenID Connect protocol to authenticate users with Azure Active Directory;
• calls Azure AD to get OAuth 2 access tokens for the Web API; 
• cache them in Azure Cache for Redis to enable multiple instances to share the same token (if necessary).

What happens when the user signs in, at a high level:

1. The tenant’s user clicks the "sign in" button in the multi-tenant SaaS app. This action is handled by an MVC controller.
2. The MVC controller returns an action to verify their identity.
3. The middleware creates a 302 response, which redirects the user to the Azure AD sign-in page.
4. The user authenticates with Azure AD.
5. Azure AD sends an ID token to the application.
6. The middleware validates the ID token and authenticates the user inside the SaaS application.
7. The middleware redirects the user back to the SaaS application.

When the user first signs in, the Cookie Authentication middleware writes the user claims to a session cookie, which gets deleted once the user closes the browser (it’s convenient for banking applications, for example, and can be reconfigured to persistent cookies). After that, HTTP requests are authenticated by reading the cookie.

Example of SaaS Identity and Access Control Management using Auth0 and Amazon API Gateway 

Basic multi-tenant setup with Auth0 and Amazon API Gateway. aws.amazon.com

Auth0 is a third-party cloud identity and access control management provider. Auth0 Organizations is their solution for SaaS owners to manage customers and partners in their B2B SaaS applications. It allows to manage the business customer’s identity, including single sign-on, role-based access control, user management workflows, and even co-branding login flows.

Create Tenants

To setup multi-tenant identity and access control management for your SaaS platform, you need to: 

1. Create Auth0 tenants using your Auth0 account. Map all your tenants 1:1 with Auth0 tenants.
2. Auth0 provides Database Connections to authenticate users with their emails/usernames and passwords* (users’ profiles). These credentials can be stored in the Auth0 user store or in your own database. You can have your Auth0 Application read that information after the user logs in. This approach allows users, regardless of which tenant to which they belong to, to log in using in a uniform configuration.
3. Create two Auth0 Applications. The first one is used to allow users to authenticate to the SaaS application. The second one is used to onboard new tenants and invite tenant users.

*Different authentication methods can be used within the same tenant:

• some users authorize through an enterprise identity provider and others by email/password;
• a separate database connection and stricter security rules may be utilized for the root user within each tenant, while standard tenant users are stored in separate connections. 

Onboard New Tenants Using a Registration Form

A SaaS registration service (AWS Lambda in this design) orchestrates calls: 

• Tenant microservice creates a new tenant entry in your backend database.
• User microservice will be invoked to invite the user to the tenant’s Auth0 Organization.

The Auth0 Login Flow

Control Access to Resources and Actions Based on the Permissions of the User

1. Assign specific permissions to individual users or create roles with a set of permissions that can be granted to a group of users in an Auth0 organization. 
2. When an application requests an access token for a specific action, it specifies the required scopes. If the user has the appropriate privileges, Auth0 returns an access token with the requested scopes. 

Belitsoft SaaS development company specializes in creating multi-tenant applications with custom authentication and authorization modules to protect sensitive information and properly control user access. If you want the best solution for managing tenants and data in your SaaS application, look no further. Contact us today to learn more about how we can help you build a secure and scalable SaaS application.