Ask HN: Technical Challenges in Building Multi-Tenant SaaS Products

[barnabas-szoke]

Hello Community,

I'm in the process of exploring the development of a SaaS product and am keen on understanding the landscape better from those who have walked this path before I jump into coding. Specifically, I'm looking into creating a B2B multi-tenant identity management platform for SaaS businesses.

These are the main questions that puzzle me most:

- Main Technical Challenges: What are the primary technical hurdles you've encountered in building and scaling SaaS products? Especially interested in aspects related to multi-tenancy, security, tenant management, and onboarding.

- Market Need: In your experience, is there a significant demand for a streamlined, multi-tenant identity management solution? How critical is identity management in your time-to-market considerations?

- Product-Market Fit: For those who have implemented or considered such solutions, what features or capabilities do you find most lacking or desired in the current offerings?

- Choice of Providers: Which identity management providers have you used for your SaaS products? What influenced your choice? Any pain points?

- User Experiences: What have been your experiences with these providers? Pros, cons, and any specific challenges you faced, especially in terms of multi-tenancy and security?

- Building Custom Solutions: Have any of you opted to build your own identity management solutions instead of using existing providers? What led to this decision, and how has it impacted your product development and time-to-market?

- Desired Features and Capabilities: In your view, what are the most critical features or capabilities that are lacking or could be improved in current identity management solutions?

My goal is to validate the need for a solution that simplifies identity management across different tenants.

Any insights, experiences, or advice you can share would be incredibly valuable and much appreciated. Thank you for your time and looking forward to the discussion!

[AaronM]

The big challenge that I remember from building a product is making sure customer A never sees customer B data.

So all of your messages end up passing some sort of customer identifier everwhere and you need to enforce checking it at the lowest possible levels

[barnabas-szoke]

How did you solve that? Did you go for a siloed model or a pool/hybrid model with some kind of row-level security (or something else)? Did you have any specific reason to build your custom solution instead of using a managed service offering like Auth0 / Clerk, etc...?

[codegeek]

A few:

1. Custom domains per tenant (if relevant). For example, if you are building a platform like shopify where each tenant gets their own domain, this is an interesting challenge. Services like cloudflare for SAAS cost an arm and a leg and they restrict apex domains unless Enterprise plan (read six figure per year). You could build your own using something like Caddy with TLS Termination and auto certificate issuance but it's tricky to build for scale (I played around with a prototype for this so I have some learnings from it)

2. Initial Tenant Provisioning specifically their data. Do you have db per tenant or 1 single db for all tenants ? If SIngle DB for all tenants combined, how will you do data isolation and ensure that one tenant doesn't accidently see/process another tenant's data ? If you use multiple DBs, how do you ensure that a request from a tenant connects to that tenant's db without losing performance ? DB Pooling etc etc.

3. Tenant data management after provisioning. Let's say you have DB per tenant. How will you apply a migration across 100s of DBs effectively, accurately and with speed ? Can you customize one specific tenant if they are like enterprise ? How do you handle their migration now ?

There are some of the most challenging aspects. There are many others of course.

[barnabas-szoke]

Great insights and valid technical challenges, thank you!

[miravmehta]

Sure, here are the corrected sentences:

1. RBAC Policy When there are multiple types of roles in a parent-tenant (pt) and child-tenant (ct), there could be cases where some resources can be shared between pt and ct, while others cannot. Hence, conditions to access these data are not limited to RBAC, but also depend on the type of data and metadata. Checks are applied on metadata.

2. Architecting Multi-Tenant A significant challenge would be in schema design, especially the isolation of pt and ct. There are open-source solutions available that provide pre-cooked solutions, yet they may not be as effective as writing your own.

3. RBAC can go beyond ABAC and REBAC This is an advanced problem. Customers in the cloud-native space have demanded this before as it provides granularity. This is heavily backed by your RBAC architecture. If that's implemented incorrectly, then your ABAC and REBAC will also be affected.

[barnabas-szoke]

Thanks for your answer.

1. I am not familiar with the parent-child tenant relationship in auth. Could you elaborate on that? Is it like some sort of logical relationship between a holding company and subsidiaries or maybe different cost centers in an organization?

2. I agree. Managing the schema changes in a siloed multi-tenant platform can be a nightmare. I would be keen the have a look at those open-source pre-cooked solutions.

Based on your response it sounds like you wanted to design/build a custom auth solution. May I ask what was the main motivation? Did you have any other pain points with the current offerings?

[miravmehta]

[1] MSP is the term for this. Managed Service Provider Lets say my company has a SaaS product. AT&T is the customer to my company and i onboard them to my SaaS platform, now AT&T has a customer called "Dell" and AT&T wants to onboard Dell to this platform ; Essentially white-labelling

Parent- AT&T Child - AT&T

[2] We have SaaS platform build like Backstage, Vmware Tanzu. We didn't wanted to build custom auth solution, this was a demand from customers who wanted granularity not just based on CRUD operations but based on environments, access to type of metadata, projects, other app-services

We had something called soft-multi-tenancy, where user "abc" can access namespace in k8s in cluster B, but not cluster A; because B (child) is inherited cluster from A (parent)

Examples of RBAC granularity

1. Write access to Namespace (can change, Namespace, pods, deployment and more .. based on k8s first class object) 2. Read access to Namespace 3. Write access to Pods 4. Read access to Pods

Just like this we had close to 20 RBAC granularity

I recommend you reading about RBAC, ABAC, RE-BAC, Soft Multi-tenancy ; companies who are building this loft.sh, rancher. Our solution was not focused RBAC at all, when we bough multi-tenancy it enforced us think through RBAC

[barnabas-szoke]

Thanks very much, it makes sense now.

[mffap]

One of the challenges we see is providing self-service for team management. That includes letting an admin assign roles to their users, manage user lifecycle (eg through sso), and setting up security policies. For sure you can build the basics, but it becomes complex later on if you manage a lot of tenants or or more enterprise customers. For Auth only there are many solutions out there that work great. There's only a few solutions with multi-tenancy at the core, though, like https://github.com/zitadel/zitadel

[barnabas-szoke]

Thanks for your answer. Zitadel looks promising.

1. Could you elaborate on the RBAC challenges? What is the main complexity?

2. What is the main selling point of Zitadel in terms of multi-tenancy compared to the competitors?

3. From your perspective, are you aware of any customer segments or niches that are underserved in the IAM market in general that might be worth pursuing?

[mffap]

For RBAC, I see two main challenges. You need to make sure that you get all the roles for all client applications for a user to make a decision. That becomes a bit more complex if you go into scenarios where each tenant can also manage their own clients and roles. Secondly, complexity comes from the self-service to assign roles, ie. delegating access management to the tenants. You need to allow certain users to assign the roles to users in their organization, or in general manage their users. That authorization model has to be applied to the whole system, including APIs obviously.

Most solution solve the authentication part, so login with a local user or federated users via identity brokering (eg, OIDC/SAML via EntraID). The main selling point of ZITADEL is that it also solves the authorization, as mentioned above, across multiple tenants as well as the self-service aspect of delegating configuration of security policies and user management to "Managers" in the tenants. You get that out of the box, no development needed. You can read more here: https://zitadel.com/blog/multi-tenancy-with-organizations Also, you can self-host ZITADEL which is not available for all solutions, but is quite a selling point when talking to enterprise customers.

I think the b2b niche was already mentioned in this thread. But I don't think it is underserved, as many vendors jump onto that. Healthcare and Manufacturing are two sectors that are hard to crack with IAM for their special requirements. The tools I've seen are working but very expensive and customized. Yet also the two sectors are very traditional (read: on-prem AD) and need a lot of work if they want to move to more federated IAM systems.

[grinich]

We at WorkOS have been building this for a few years.

It seems like a clear need in the market, and other players like Clerk and Stytch have pivoted from consumer->b2b auth too. Not to mention Auth0/Okta.

The CIAM category is so broad that I would suggest to start narrow in a more “niche” area, such as auth for healthtech products, or focusing on permissions/rbac. When you go narrow, you will be able to provide a stronger product than the incumbents which are constrained by their breadth.

Happy to chat more. I love helping founders. Feel free to email.

[barnabas-szoke]

Thanks, I would be very keen to understand your view on the market. Will drop you an email. Cheers.