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.