Hi, Padmaraj. Gluu can't offer anything we clearly advertise as "multi-tenant", but perhaps if you could explain your requirements in more details, we could try to find some solution which will meet them.

Hi, I think multi-tenant capability would be a really great asset for gluu server. Let's consider this scenario: ACME business provides a SAAS, where each client is another company: - company1.acme.com - company2.acme.com Each company would want to individually theme its login page and fine tune its tokens properties (like expiration time, whether it's opaque or not and so on). A user (identified by an e-mail address) could have accounts on both companies with different passwords and MFA setup. From what I understand, the only solution to accomplish this is to deploy gluu separately for each tenant, which quickly becomes unmanageable given thousands of company clients (those servers need to be deployed, replicated, DR).

Yes Florin, that is exactly our scenario. In fact all companies offering services would have same kind of need.

Hi All, Multi-tenant capability can be achieved in a couple ways: 1. As you mentioned, a separate Gluu Server can be hosted for each customer. I agree this is not especially easy from a management perspective or scalable as the number of customers grows. 2. There are typically a few ways a SaaS app achieves multi-tenancy for customers: separate machines, separate VMs, and separate containers are three common methods. If your SaaS app follows any of these patterns, each customer instance can be treated as a separate OpenID Connect client in the Gluu Server OP, and can then request its own login page and custom logic using OpenID Connect ACRs and Gluu interception scripts. So in your example above: - `company1.acme.com` and `company2.acme.com` would each have their own OpenID Connect Client in the Gluu Server OP. - When a user navigates to `company1.acme.com` and clicks login, that "client" would pass along a unique acr value to the Gluu Server, for instance `company1 auth`, which would correspond to an interception script that determines which login page(s) to present, and which type(s) of authentication is required. There are many ways to achieve your unique business objectives with the Gluu Server. To achieve the exact desired UX and functionality, typically some custom development is required. If you have budget, I'm sure one of our [service partners](https://www.gluu.org/partners-service/) would be happy to help. Thanks, Will

Hi i understand this is an old post, but its the only one that shows some form of a solution. Can anyone provide some insight on how this can be done from a high level - for someone newish to Gluu?

True Multi-tenancy is not supported in any meaningful sense. The above solutions i presented are more workarounds. Multi-tenancy adds a bunch of complexity for a security product like Gluu. If you need to separate users, the best solution is to deploy a separate Gluu server for each user base. If you need to simply show different login pages to different apps, you can use OpenID connect acrs. Thanks, Will

Thanks WIlliam. We are doing a POC of Gluu at the moment - and we used docker to deploy it. If that is the case and we need to deploy a seperate server - do we need to deploy all those services? I understand docker edition is only suppored for those with a support agreement - but my question is about resources. Looking at the install doc (non docker), it states 4Gb minimum. We are only expecting about 10-30 user accounts per Gluu 'instance', so running a VM with 4Gb for just 30 users is going to be quite resource heavy and not too scaleable. When i look @our docker stats ( i deployed a 4Gb ubuntu 18.04 VM with just docker installed to test out Gluu), i can see that oxauth is taking 725Mb of memory, oxshibboleth and oxtrust are the next 2 hungry ones at 550Mb each. Adding all of the services - its around 2Gb of memory. When i look @ the Gluu UI - it shows i have 35% free memory (on a 4Gb VM). So circling back to my question - will all these services have to be deployed per instance, or is there any that can be common? Cheers

Hi, The DE repo and all the individual DE components are actually licensed under the [Gluu Support license](https://github.com/GluuFederation/gluu-docker/blob/3.1.4/LICENSE), which means a support contract is needed with Gluu or one of our OEM partners for use after 30 days. > running a VM with 4Gb for just 30 users is going to be quite resource heavy and not too scaleable. Agreed. Whats the business case for multi-tenancy? The value of the users would need to be very high to justify the costs associated with deploying and operating a dedicated authentication service. LDAP, oxAuth, and oxTrust are all required for your OpenID Connect service, so you need those in each instance of Gluu. SAML is optional, but a memory hog, and it sounds like you need that as well since you mentioned Shibboleth is installed. That too would need to be installed where ever you want to support SAML. We specify 4GB because you don't want your authentication service to run out of memory and crash.. with so few users, you might be able to get by with less, but it's not something we recommend or test for. In general, Gluu is built for high-end requirements, so unless the value of the users is very high, I'm not sure this is a good use case. If you'd like to discuss technology / business further, let's do it on a call. Just grab a convenient time: https://gluu.org/booking Thanks, Will