Which IAM SaaS architecture is for you – exploring IAM architectures in Software-as-a-Service solutions

As a penetration tester specializing in Identity and Access Management (IAM), I find multitenancy particularly fascinating. From the security perspective, it introduces unique opportunities to explore – and, often, to exploit. This is because in multitenant applications, the attacker’s perspective shifts as the potential threat actor grows in power. 

Usually, the most common attacker is a low-privileged application user. However, in multitenant applications, the most serious threat comes from a tenant administrator – someone with far more privileges and an entirely different goal: accessing other tenants. 

Working as an IT Security Consultant gives me a unique perspective across real architectures used by our clients. These setups might not always be perfect, but they are the result of innovative solutions, real-life business constraints, and, of course, various shortcuts to stay on time and within budget. For many organizations, the journey from standard password authentication to modern Single Sign-On (SSO) solutions has been long and eventful. Today, it’s essential that both old and new systems work seamlessly together. 

In this article, I’ll review common Software-as-a-Service architectures from the identity management perspective and discuss potential threats that come from multitenancy. 

Download a collection of threats described in this article for your own convenience and check whether your organization is at risk:

SaaS architecture fundamentals 

When evaluating potential SaaS architectures, IAM might not be the first thing that comes to mind – and that’s perfectly fine. Once you’ve nailed down the core aspects of your solution, you will find many options to consider. 

Will you opt for multitenancy, which offers cost-effectiveness and scalability, or single tenancy, which provides complete data isolation and a high degree of customization? If you decide on a multitenant architecture, at what level will the separation between different organizations occur? 

Let’s say you’ve already determined the type of tenant isolation you need – whether it’s multitenant (pool), hybrid (bridge), or single-tenant (silo). Now, what about user management? For SaaS, one of the most important enterprise features is the ability to integrate with your customer’s Identity Provider (IdP). This integration is no longer just an added value, but often a key requirement when selecting the right solution. 

Make your Single Sign-On capabilities a selling point – not a burden and a security liability. 

Will this integration occur directly between your application and the customer’s IdP, or will you use another IdP as an intermediary? 

With this question in mind, we’ll now explore possible SaaS IAM architectures. To keep the diagrams simple, we’ll focus primarily on IAM architecture, leaving topics like database isolation out of scope.

Connect with the author on LinkedIn!

SaaS IAM architecture types 

Single Tenant 

With single tenancy, the scenario seems relatively straightforward. However, there are still several possibilities to consider. The first option is to design a built-in user repository, which involves creating the processes to manage users, their credentials, and their permissions internally. The second option is to leverage an existing Identity Provider (IdP) and integrate it with your application using Single Sign-On. To maintain a consistent design throughout the application, you might also consider creating a custom UI for the IdP. 

As mentioned, most customers will be interested in integrating your SaaS with their own Identity Provider. However, the integration and provisioning requirements can vary between your enterprise customers, bringing a new edge case with every onboarding. An existing IdP will likely provide various integration options along with comprehensive documentation and community support. Without it, you’ll need to develop the integration component in-house. 

The most important threat actors are anonymous attackers as well as a low privileged users. Their goals could be: 

• Authentication bypass or MFA bypass. 
• Account takeover, e.g., via insecure password reset process. 
• Privilege escalation, e.g., via manipulating own permissions. 
• Gaining access to the user management panel to create new high-privileged users. 

For single tenant architecture, the standard application threat model applies, and we don’t have to worry about a threat actor exfiltrating data from different organizations. However, single tenancy is not always a viable option and might only be available to selected customers with higher subscription tiers. 

Multitenant with self-configured Identity Provider 

With multitenancy, the situation becomes more complex. Ensuring proper data isolation between different organizations requires special attention and can become challenging, especially when users are allowed to belong to multiple organizations. 

Let’s examine some potential threats in such architecture. This time, the main threat actor is an administrator of a malicious tenant – but of course, the single-tenant threats mentioned earlier also apply. While certain threats may vary depending on the specific isolation model employed, in my experience, the following areas are typically the most critical to analyze. 

Single Sign-On:

• Modification of another organization’s SSO configuration (tenant takeover). 
• Deletion of another organization’s SSO configuration (Denial-of-Service). 
• Accidental global enforcement of an SSO configuration (e.g., one tenant’s SSO configuration works for every organization in the application). 
• Vulnerabilities in the implementation of SAML or OIDC. 
• Account pre-hijacking (e.g., creating an account using a victim’s email address before the victim signs up, potentially gaining backdoor access to the victim’s account if the victim uses Single Sign-On in the future). 

User synchronization (Just-In-Time, SCIM, or manual): 

• Insufficient offboarding. 
• Hijacking a different tenant’s user. 
• Provisioning a user to another tenant. 

User in multiple organizations: 

• Abuse of the context switcher to gain access to a different tenant. 
• Modification of a user from a different tenant after inviting them to your tenant (e.g., changing their password). 
• Improper evaluation of authentication context (e.g., if the user logged in using a specific tenant’s SSO, they should not be able to switch tenants). 
• Improper permission management for a user in multiple organizations (e.g., if a user is high-privileged in one tenant and low-privileged in another). 

User management: 

• Creating a user account in a different tenant. 
• Creating a user with the same username or email as in a different tenant leading to account takeover. 

And obviously, don’t forget about access control, which is always a challenge in any multitenant application! 

Multitenant with shared Identity Provider 

In this scenario, the multitenant SaaS application utilizes a single instance of an Identity Provider that (hopefully) supports multitenancy – such as Keycloak, which allows you to create separate realms for different organizations. 

It’s important to note that even if some tenants appear to be separated, but they are still integrated with the same Identity Provider instance as the rest, they should also be considered a part of the IAM multitenant infrastructure. 

Even though we use a shared IdP for all tenants, it doesn’t mean that organizations wouldn’t like to integrate their own IdP. In this case, the Single Sign-On configuration will likely be handled by your customer support team, as you won’t provide customers with access to your IdP administration panel. 

The most crucial aspect here is to ensure that user accounts remain isolated between different tenants.  How easily this can be achieved depends on the IdP you choose. Potential threats specific to this configuration include: 

• Accidental global enforcement of SSO configuration (e.g., one tenant’s SSO configuration works for every organization in the application). 
• Modification of user groups or permissions, which could grant them access to a different tenant. 
• Unauthorized access to IdP administration panel (e.g., via improper configuration, usage of default credentials, or credential breach). 
• Lateral movement between different Relying Parties (if you use the IdP not only for multiple tenants, but also for multiple applications). 

How to design SaaS IAM architecture? 

I don’t think there is one perfect SaaS architecture. Each has its own set of challenges – some are less prone to mistakes, while others are easier to implement. Often, we don’t have the chance to fully plan the desired outcome and need to adapt, taking shortcuts along the way.  

From my experience, the most common problems in multitenant applications are IAM mistakes and improper access control. These issues are always critical, leading to unauthorized access to another tenant’s data. I would like to discuss such a case in my next article, which will be a case study on a critical misconfiguration I identified during a penetration test.  

I hope this article gives you a better understanding of potential threats and helps ensure they won’t impact your application. However, if you ever need a deeper analysis, feel free to reach out for a pentest! 

References 

• AWS Well-Architected: SaaS Lens 
• Relevant Software: Multi-Tenant Architecture for Designing a SaaS Application 

Connect with the author on LinkedIn!

Natalia Trojanowska-Korepta Senior IT Security Consultant