Now there is a serious problem here with scaling. Each Keycloak instance would take as much as 700 MB of RAM. Even the new shift to Quarkus takes at least 300 MB.
This hugely reduces our ability to deploy one Keycloak instance per customer.
However, Keycloak has the concept of realms, which in essence is the multitenancy architecture.
This is good news for us. This means that we can use accounts.our-company.com as the single identity management access point for all or our customers, example1.com, example2.net, another-site.another-tld.
But we lose branding here. We would love to have accounts.our-customer-domain.tld as the accounts management subdomain.
So, this is the question I have. Is it possible to make that KC_HOSTNAME dynamic? In other words, is it possible to have one Keycloak instance serving on different hostnames?
That definitely helps. Users of exampe1.com with red theme would see a red login page and users from example2.net with blue theme would see a blue login page.
But if they both look up, they both see accounts.main-domain.com.
Since we’re selling websites to our customers, they panic if they see that their user accounts are not on their main domain.
We want users of x.tld to see accounts.x.tld when they are redirected to this single Keycloak instance. Then behind the scenes, they would be using a different realm.
The proxy in Apache, or whichever you may select to have, resolves the customers domain, and all else under the hoods are proxied to the appropriate realm (who’s ‘real’ domain is never seen outside of your network borders).
That is good advice. Thank you for that. But there is a problem. Keycloak uses accounts.our-compoany.com to create a lot of links for redirections. And users would encounter problems when they want to navigate.
For example, a user goes to accounts.example1.com and sees the red login page. But he does not remember his password and clicks on the forgot password link, and what happens then? Based on the docs, user would be redirected to accounts.our-company.com.
The clients don’t have to be named to a specific client. That’s just to make the example clearer.
example1.com would have to know enough about it’s environment to do the redirect to example1’s custom realm login page. For instance, if no token the pull the domain and use that for the realmId and the clientId
I understood. We should implement redirection in our reverse proxy or load balancer ourselves. This seems to be a practical solution.
However, since I’m not a Keycloak expert, I don’t know if this results in some sort of problem somewhere or not. For example when clients want to query well-known resources. Or when they want to refresh a token.
I would appreciate it a lot if a Keycloak expert or a Keycloak team member would also give us a hint regarding this requirement.
Refreshing the token is fine – that’s core Keycloak whether or not you’re doing a multitenancy design
There are going to be differences between giving each customer a full Keycloak and deploying a single instance. My customer needs high availability and clustering and it’s not feasible to give each customer their own multi-server infrastructure.