The Complexities and Pitfalls of Multi-Tenant Identity and Access Management

Imagine this: Dave, an IT manager, is responsible for overseeing access for multiple tenants within his company’s cloud service. He has User A from RetailCo and User B from FinanceCorp, both needing access to the same service but with completely different security requirements. User A prefers logging in with their Google account and demands strict password policies. User B uses their company’s Azure AD and requires multi-factor authentication. Dave thought managing a single organization was tough, but this? This is a whole new level of complexity.

As if that wasn't enough, Dave’s company is rapidly growing, introducing more customers from various industries, each with unique compliance and security requirements. Now he has User C from TechInnovators who needs passkeys for enhanced security, and User D from EduWorld demanding seamless SAML integration with their existing single sign-on system. The more tenants Dave’s company takes on, the more convoluted and headache-inducing his job becomes.

Understanding Multi-Tenant IAM

Implementing multi-tenant Identity and Access management (IAM) systems can be complex, daunting, and filled with hidden challenges. Whether you're addressing the needs of B2B, B2C, or M2M (Machine-to-Machine) environments, multi-tenancy involves a single service instance serving multiple tenants, such as organizations or customers. This requires meticulous data and component segmentation based on service needs and data types. The chaos gets further compounded with individual compliance requirements.

Consider a simple login screen—two input fields and a button. It looks straightforward, right? But this seemingly simple UI is just the tip of the iceberg. Behind the scenes, there's a multitude of complexities: username and password management, multi-factor authentication options (SMS codes, email codes, authenticator apps), passwordless authentication (face recognition, fingerprint scans), and identity brokering (social logins like Google, Apple, or Facebook).

On top of that, managing security settings, performing regular penetration testing, adhering to standards (such as SCIM, OAuth 2.0, and OpenID Connect), and obtaining certifications (like ISO and SOC 2) add layers of complexity. This is especially true when these features must be replicated across multiple tenants.

When you introduce multi-tenancy, everything becomes more complex. Each customer brings their unique requirements—username and password for one, passwordless or multi-factor authentication for another, or integration with existing identity systems like Azure AD or Google Business. These varying needs mean you must be able to configure and maintain diverse systems for each tenant, requiring significant time, expertise, and resources.

Let’s look at a real-world example. Imagine you run an online store serving end consumers, business partners, and your workforce. Each group has different needs: consumers need a user-friendly login and account management system, business partners (such as other sellers) might use their existing enterprise identity systems and may have their own branding requirements, and your workforce needs robust role and permission management to secure administrative tasks.

Yes, it’s possible to manage all these requirements with roles and permissions. However, when you consider the need for different security settings, it often makes more sense to adopt a multi-tenancy approach. As you scale to multiple customers, each one may require unique domains, branding, social logins, and security settings. Managing these variations with a roles and permissions model becomes increasingly complex and unwieldy. Multi-tenancy offers a more streamlined and efficient solution, allowing you to handle these diverse needs effectively and securely.

Questions to ask when dealing with multi-tenancy include: How many levels of tenancy do you need? Are there multiple organizations within a tenant? What scenarios are you dealing with (B2C, B2B, mixed)? Each user group might need different authentication methods, security policies, and compliance requirements (e.g., GDPR, SOC 2, ISO).

Consider the example of a healthcare application where different tenants have varying password hashing requirements (PBKDF2, Argon2, bcrypt) and audit trail needs. Protocol-specific differences also arise; for instance, integrating customers’ existing Azure AD for user federation can lead to numerous configurations and requirements.

So, do you explain outdated or incorrect policies to each customer, or make your software flexible enough to handle these diverse needs while focusing on your business case? Ideally, you want to provide a robust, flexible platform that can accommodate different configurations and compliance requirements.

From an architectural perspective, you have two main options: shared systems or dedicated systems. Shared systems are cost-effective and simpler to manage but come with lower isolation, potential security risks, compliance challenges, and performance issues. Dedicated systems offer enhanced security, compliance, and customization but require more management, infrastructure costs, and personnel.

In summary, identity infrastructure involves much more than just two input fields and a button. It's intricate plumbing work, particularly with multi-tenancy. Always remember that the customer is king: guide them on security best practices, but also ensure your infrastructure can meet their unique needs. A proven track record in security is essential for enterprise deals, so regular penetration tests and certifications are crucial. Make use of established frameworks like OAuth 2.0 and OpenID Connect, and rely on an existing IAM product, such as ZITADEL, for authentication and authorization instead of building your own from scratch.

How ZITADEL Handles Multi-Tenancy

ZITADEL has a strong focus on supporting SaaS providers with a multi-tenancy use case. This is achieved by allowing multiple organizations within your ZITADEL instance, where all customers can self-manage their own users and roles. ZITADEL operates as a shared system, but it also allows for virtual instances and separate organizations within each instance. This setup is particularly beneficial for B2B app providers where

• you sell your application to other businesses, where each business wants to manage their own users, roles, and access settings
• your customers have different needs for the login flow, such as unique branding, federated logins, password policies, and MFA options
• your customers want to self-manage their users and roles without relying on your administrative team
• users/employees of your customers need to log in or register independently
• not all customers have the same feature set within your application

How Does Multi-Tenanacy Work in ZITADEL

Create Organizations

For each customer, create an organization, the equivalent of a tenant, in ZITADEL. Assign an organization manager to let each customer manage their users independently. Furthermore, users can belong to multiple organizations and switch between them using the same identity, simplifying user management and improving the user experience.

Custom Configuration

Customers can configure their login look and feel (branding, authorization methods, federation or you can do it for them. ZITADEL supports various authentication methods, including username/password, MFA, and passwordless options. Integrate existing identity providers like Microsoft Azure AD, Google etc., allowing users to log in with their existing corporate credentials.

Domain Discovery

ZITADEL offers domain discovery capabilities, which routes users to the appropriate organization based on their login methods, whether it's a username, email, or phone number. For instance, if a user from "foo.com" logs in, they are routed to the Foo Organization, while a user from "bar.com" is directed to the Bar Organization. This ensures users are authenticated according to their organization’s policies and access settings.

Project Grants

With project grants (also known as granted projects) your customers can access your project with a subset of roles so they can manage authorizations for their users. Enable granular role management, allowing organizations to assign specific roles and permissions to users based on their needs.

Standards and Compliance

From a certification and standards compliance perspective, ZITADEL is GDPR compliant and ZITADEL’s OIDC library has been certified by the OpenID Foundation. Furthermore, ZITADEL recently achieved ISO 27001 certification for its information security management system, to maintain the highest standards of information security. ZITADEL assures customers that their data is protected by robust security measures, reflecting global best practices in information security management.

By providing these capabilities, ZITADEL simplifies the management of multi-tenant IAM systems, ensuring security, flexibility, and ease of use for both administrators and end-users. Moreover, ZITADEL provides support for unlimited users, projects, and applications, making ZITADEL a trusted, secure, and scalable solution for your multi-tenant IAM needs that can grow with your business.

This blog post is based on and expands upon the talk "The Perils and Pitfalls of Multi-Tenant Identity Management" from Cloud Native Security Con 2024, North America. For the full discussion, you can watch the video here.