The Nightmare of Modeling B2B IAM with Traditional IAM Solutions
It’s Time to Treat Organizations as First-Class Citizens in IAM
B2B (Business to Business) SaaS (Software as a Service) is booming and with it comes the need for a various kind of Identity and Access Management (IAM) requirements. But here’s the problem: most teams are still trying to shoehorn B2B use cases into traditional IAM tools built for a completely different world.
If you’ve ever tried to model organizational customers with groups or roles, or gone down the multi-tenancy rabbit hole just to keep customer data isolated, then you know exactly what I’m talking about.
Let’s dive into why this becomes a horror show for architects, developers, and product teams alike.
💡 First, a Quick Recap: Is B2B IAM New?
Not really.
B2B IAM requirements aren’t some trendy 2020s invention. It’s just that the pain has become too loud to ignore with digitalizing all most all the operations. For years, companies hacked their way through IAM systems that were built for employees or end consumers, not for organizations who bring their own customers, or partner companies.
For decades we have done what engineers do best; “workarounds” to solve IAM problems in B2B world. Let’s explore them and see why they’re giving you gray hair.
So, what were these workarounds? Primarily:
- Using Groups or Roles to model organizational customers.
- Using Multi-tenancy to model organizations.
While seemingly convenient at first glance, both approaches introduce significant headaches when building Identity and Access Management (IAM) solutions for B2B SaaS applications. Let’s delve into the problems each presents.
Workaround #1: The Pitfalls of Modeling Organizations as Groups or Roles
Access Control Becomes a Labyrinth: Imagine having to write countless conditional authentications to handle B2B SaaS application logins per customer organization. (eg: organization A uses basic auth and MFA, organization B use their own enterprise identity provider, like wise). As the number of organizations and their specific access needs grow, this becomes an unmanageable mess.
Scalability Suffers Drastically: Handling multiple organizations within a flat group or role structure leads to significant scalability issues. The more customers you onboard, the more cumbersome and slow your IAM system becomes.
Delegated Administration is Costly and Risky: Let’s say the B2B SaaS business wants to let each customer organization’s admin to invite their own users, change the application login flow for users, reset passwords, or assign roles? In a shared user pool? That’s risky business. Unless IAM provider love implementing their own fine-grained admin scopes with endless if-statements, you’ll end up with over-permissioned admins or worse, cross-customer data leaks.
Providing delegated administration, where the customer organization can manage their own users, becomes incredibly complex and risky when everyone is modeled in the same shared space.
Achieving Different UI and URL Branding per organization is a Pipe Dream: Want customer organizations to have their own login URL? Custom logo? Branded email templates? This is nearly impossible to achieve gracefully when all users and organizations are modeled within a single, undifferentiated identity space.
Workaround #2: The Challenges of Using Multi-Tenancy for B2B IAM
Another common strategy is to spin up a separate IAM instance or tenant per customer. This isolates users and data by design, which feels like a win, but the downsides sneak in fast.
Isolation vs. Sharing Dilemma: While multi-tenancy provides excellent resource isolation, B2B SaaS often requires a delicate balance of resource isolation and resource sharing. For instance, a user might belong to multiple organizations or access shared resources across different tenants. This often leads to the cumbersome duplication of user identities across different isolated instances, creating data synchronization and management nightmares.
🤹♂️ Why is achieving B2B IAM requirements with traditional IAM solutions this so hard?
Because B2B IAM is full of contradictions:
- You need resource isolation, and also resource sharing at the same time.
- You want scalability to handle thousands organizations with generic features, but also customizability per organization is a key.
- You need the control of governing all customer organizations from service providing organization-level, but also delegate functionalities to customer/partner organizations to cater flexibility.
Trying to handle all that with traditional IAM tools is like building a five-star hotel on top of a single-family house foundation.
🧭 Where do we go from here?
Now it’s clear: we can’t keep hacking around groups and multi-tenancy to model business customers. What we need is a first-class identity construct for organizations.
To handle real-world complexity, it’s not enough to just “tag” users or create isolated silos. Instead, organizations need to be modeled as hierarchical entities which are capable of supporting not only resource isolation, but also resource sharing and inheritance. That means a single organization could contain multiple sub-orgs, teams, or divisions, and the identity system should allow them to share policies, users, and resources in a controlled and flexible way.
In other words, organization management becomes a key enabler for B2B IAM.
But here’s the nuance: not every B2B use case maps neatly to a single organization structure. The B2B world is messy and diverse. Some use cases need full org hierarchies with delegated admin and deep branding controls. Others are simpler perhaps just needing a few groups, or tenant-level isolation with occasional cross-access.
That’s why B2B IAM isn’t one-size-fits-all.
So, selecting a B2B IAM provider isn’t enough to solve your identity management chaose in your B2B applications. You also need to accurately model your specific B2B use case considering set of checklist items like:
- What is the application login experience per each customer/ partner organization?
- Whether same user identity can access multiple organizations?
- Do customers need self-service capabilities and delegated administration?
- Are there branding or SSO requirements per organization?
- ……….. and so on
So, picking a B2B IAM vendor isn’t just a buying decision; it’s an architectural decision.
In the next posts, we’ll dive deeper into:
- Why B2B IAM can’t be boiled down to a single pattern and why it has different flavors
- The spectrum of identity needs across different SaaS models
- What are the different login experiences in B2B applications
- Different user identity modeling methods for different usecases
Until then, take a moment to explore the organization management capabilities of WSO2 Identity Server and Asgardeo. These platforms are already tackling many of the challenges we’ve discussed, and can offer a strong foundation for modern B2B IAM strategies.
See you in the next post! 👋
