Hello, I have searched GH issues and the Slack history but I am not understanding how to setup multi-tenant with Ory Cloud where each tenant can manage their own federated IDs, user provisioning, role mapping, etc. Anyone have a guide or list of bullet points?

Hi @echoing-lunch-81617 Ory Cloud does not support multi-tenancy. Maybe you can chat with us on your use case and how we can accommodate you. /cc @fast-lunch-54279

Thanks @proud-plumber-24205 and super bummer (and inconsistent with messaging from sales). Use case is typical for B2B SaaS: • Organizational tenants where individual users can be members of an org. • Orgs can self-serve configure their federated IDs, user provisioning, and assign/map users to roles reconfigured roles. • Shared compute is great, but an user that does not have membership in the org and the appropriate role can not change that org's settings. • We use the check-API in our software to ask if a user is a member of the appropriate group/role but also if the user is a member of the org that is listed in the requested resource's data model.

Hey Tom, thanks for asking, great question! You would create a Project per tenant, and you can easily do that programmatically via the API or using our CLI. Then each project has their own set of users/customers.

I think @proud-plumber-24205’s message can be misinterpreted depending on context. Ory Cloud is a multi-tenancy system and you can create tenants of Ory easily using the Ory CLI or the Ory Cloud API by creating new projects. Each project can be individually configured and the data will be isolated between tenants. If you had something else in mind let us know and we can have a chat 🙂

Yeah i think "multi-tenancy" can mean many things depending on the context. I meant a singular Ory Cloud project is not multi-tenant. Sorry about the miscommunication, I should've been a bit more precise 😅

Thanks for the continued discussion and clarification. I did not take @proud-plumber-24205 comment to exclude the mulitple projects path. The separate projects will not work for our case. We would need to build a control plane of sorts to provision, configure, and decommission but also we would have another $20/mo fee per customer for a non-social BYOID where our model has a freemium tier and we want every customer to BYOID. For comparison, GCIP charges $0.15/MAU with a federated ID rather than $0.0055/MAU for a social login or email/password (Google Cloud Identiy Platoform does not have authorization so we would still look at SpiceDB or Keto or something else to in addtion to those prices). GCIP also only provides APIs so we are rolling our own for everything else but to use Ory Cloud Projects were will face a non-significant amount engineering too.

If the pricing model does not work for your case, we can definitely work on that and I’m happy to connect you to someone that could help in this case. The biggest cost driver for “more or less idle” projects is if you set up a custom domain, as we use a third party service for it. So if that’s not a problem for you for example we could probably do something about this base fee! But I’ also don’t really understand the use case or what you need exactly. Maybe you could give an example or link to a demo of how your product is working? Regarding pricing, I’m not fully understanding what you mean with federated or social ID. But even if Ory is more expensive, you get a much better product with more capabilities than using Google’s firebase-auth based solution! 🙂 Because you get permissions, full MFA (e.g. webauthn, apple pass keys, …) support, and also a product that is improving quite a lot every month. I’m not sure how it is for Google, but as far as I know it’s a reaction to offer something like AWS Cognito on GCP and it might not have the same ambitions to a good product as Ory has 🙂 If you ever used AWS Cognito you know what I mean 😉

Its not just the pricing (which matters when wanting all customers to BYOID), but also the forced multi-tenancy model. We are not using seperate instances of the software like Slack or Ory Cloud. So if we had separate projects for each customer, we would need to do a directly look up on the userid before authenticating them in order to find out which Ory Cloud URLs to use for that users or something like that. I mean we could make it work right, but why do the contortions? I do not consider separate instances as multi-tenancy at all. Google Cloud Identity Platform is not Firebase Auth. We do not need to dog GCIP to discuss the Ory Cloud multi-tenancy model's alignment with my needs, but several orders of magnitude on pricing for somethign that is not actually multi-tenant is not something to dismiss lightly - no matter how much I would prefer open source. WSO2's Asgardeo also supports multi-tenancy without a separate instance per tenant. Im not sure what providers such as Auth0 B2B does because I haven't given proprietary providers much attention yet. At least from my persepctive, it would be a much better experience to clearly discribe that Ory Cloud is not multi-tenant but there is nothing stoping someone from having many projects if that works for them. My frustration is coming out because of mixed messages in the docs and issues along with a sales call where I was told it did support multi-tenant without separate projects and I could just use the dedicated support offering to sort it out, I burned more than a day of engineer time starting the implementation.

I hear you, sorry that this has not gone to your liking. If you're sharing the „user pool“ in one central system and just care about an organization ID, I do think that we can do what you need. If you don't want to share the user pool (so each tenant can have the same user jane@example), then you'll need to set up one project per tenant. But could you explain what BYOID stands for? I assume it's bring your own ID, but I have not yet seen this terminology.

Ha, no "writing off", I really liked what I have experienced tech, UX, and that its real open source not some bs open core game. The only thing frustrating is the ambiguity around the multi-tenant messaging. Not being the right fit isn't a good or bad thing, there is just a need to get to the bottom of that determination without so much hassle. Shard user pool is absolutely fine. Social logins will be unique, "enterprise" federated IDs (SAML, SCIM kinda thing) can require a domain or realm. Im just after allowing tenants to operate autonomously from one another, with different configurations and users (self-serve), even though they are part of the same instance of our application. It sounds like the only way to do this with Ory Cloud is to have a project per tenant. I see how this is possible, but it not seem very attractive for complexity and price reasons. It seems like this the place to get some real answers so I am interested in learning that it wouldn't be that much. That Google Cloud product comparison page describes three distinctly different solutions: Identity Platform, Legacy Firebase Auth, Firebase Auth with Identity Platform. Multile instances of Legacy Firebase Auth would not be considered multitenant but the other two solutions do support it. I just used GCID as a market example of multi-tenant capabilities and pricing. Id rather learn about Ory here.

Thank you for the thoughtful response! It's around midnight here but I'll try to get a response in over the weekend :) Have a great weekend and I hope you can find some time to hack code and relax

Thanks @high-optician-2097 I agree that there is not one right way to do multitenancy. Here's my perspective: As long as the logical isolation is available there is a huge range of resource isolation. When that resource isolation is provisioning completely separate instances it becomes more of a hosted or virtualized model. A single instance of the software should serve multiple tenants to be multi-tenant. I think separate kafka clusters does not make multi-tenant kafka, no matter out streamlined the ops are, whereas pulsar has an hierarchical authentication model that yields first class multiple tenants on the same software. On face, console.ory.sh appears to be a multi-tenant control plane that is provisioning completely separate instances Keto and Kratos for each Ory Cloud Project. What is logical isolation but authorization? So I dont think there is really any catch to supporting multiple tenants with one Keto, but for self-serve a tenant needs to be authorized to change only the permissions that do not effect others. Even if RBAC with predefined roles was the only self service option, then tenants do not need to write to Keto at all, just decide which of their users were labeled with which roles (I think, what am I misunderstanding?). Kratos seems a bit trickier but probably because I dont understand, both how to provide tenant with self-service capabilities and to have the logical isolation. This is the kicker - Its complex and there are so many options right? The term, multitenancy, seems to have some overload too, like 'data-mesh' and "devops'. I think a a doc explicitly describing Ory Cloud's, Keto's, and Kratos' multitenancy positions would be quite helpful. Even better would be the addition of implementation guides for one or two of those "right ways" that are compatible with Ory. Product compromises are made all the time in going to the market so my ideal might be less important than whats available when looking for vendor/partners. I can send in an RFP, but I dont need to do that with other vednors and would only do it because Ory is open soruce and not open core (please dont let VC pressure changing this model!). Do you think there is a fast fail with how I have described multitenancy? I am after one UI for all tenants - like the rest of our app - with members of the tenant able to manager their own teams, permissions (even if just assigning existing roles), and federated SSO.

Hi Tom, sorry I overlooked this reply. A quick writeup of your intended target structure would be very helpful - in particular what is shared (general UI, OAuth clients, permission schemes?) and what is isolated (user pools, ...?). Or we could have a quick meeting to discuss - I'm currently working through multi-tenant scenarios and would love to cross-check my thoughts and validate against your requirements.