Can Different Tenants Have Their Own Custom Domains [Self Hosted - Community Edition]

firrae

Curious if each tenant can support having their own domain. In my can I can see using the community edition across multiple apps I have been working on, but would like, if not need, to support having something like the following:
auth.x.com
login.y.com
auth.z.ca

Where x, y, and z are different tenant TLDs. I see in the documentation that there is a "issuer" domain and theme, but I'm not sure that is an answer to this question?

dan

Hiya.

There is currently no support for explicitly assigning a domain to a tenant. If this is an important feature for you, please file a GitHub issue.

Some alternatives:

you could run multiple FA instances, with each instance having only one tenant. This means more management overhead.
You might be able to make it work by installing nginx or another proxy in front of FusionAuth. Then you could have foo.com be forwarded to fusionauth/oauth2/authorize?tenantId=A and bar.com -> fusionauth/oauth2/authorize?tenantId=B. For API clients you could use set the tenant header (X-FusionAuth-TenantId) in the proxy based on the origin hostname.

If you do the second, I'd love to see the proxy config; you could even share it in our contrib project: https://github.com/FusionAuth/fusionauth-contrib

Hope this helps.

firrae

So would FA have an issue responding to requests from a domain different than its root domain (do you even set a root domain)?

Setting up NGINX in front of it was going to be the path I took no matter what, I just figured it would want a specific root domain or there would be a way to set root domains. My app stack requires something like the following:

Client/app -> App load-balancer (NGINX/Traefik) (SSL termination) -> Internal services

If FA isn't expecting requests to come from a specific domain, then I guess this would work fine from what you mentioned.

dan

Yup, FusionAuth has no issue responding to requests from a different domain.

ralph

I've been looking at something similar here too. I'd like to ensure that hitting up auth.site1.com can only "see" the "site1" tenant. Likewise, auth.site2.com can only get to the "site2" tenant.

I've got some distance with this. When I hit up the root (or in fact any URL) I can have Nginx add in a tenantId=xxx query string parameter. This seems to work, in so much as FusionAuth returns the correct tenant login screen (confirmed by styling changes to each tenant). As Nginx is doing this out of the reach of the user, there's no way a user could get to the wrong FusionAuth tenant - although there are some things a user can do which I'd rather they couldn't.

There is one problem I can't seem to solve though. That is, if you hit up the root of auth.site1.com, you get a redirect to /login. That then redirects to oauth2/authorize, along with some cookies and a query string which includes the client_id.

The problem I have is that the client_id returned always seems to be the FusionAuth one (ie. the 'root') - even though it's not in the correct tenant. This leads to a confusing outcome because you can't log on with the users in the tenant. If I correct the client_id, then all is well.

It seems to only solution is to have Nginx intercept the query string, correct the client_id and then pass the request along (additionally including the tenantId=xxx query string variable). This is somewhat at the edge of what an Nginx reverse proxy can do, so it's looking like that FA redirect with the wrong client_id might just be the end of this endeavour (unless maybe I add in LUA into nginx or something similar).

dan

@ralph

You might want to check out this Github issue (and vote it up, too): https://github.com/FusionAuth/fusionauth-issues/issues/632

As it seems to be similar to what you are trying to do.

It looks like changing request parameters doesn't seem too tough, but maybe I'm missing something? Here's an SO answer with an example: https://stackoverflow.com/questions/34254155/how-to-change-request-parameters-before-passing-request-to-nginx-reverse-proxy-s

ralph

I've been hacking with this for a long time, and whilst I think nginx can technically do it, it's likely to be over-complicated and problem-prone (see the comments about "ifs are evil" in the nginx doco).

Instead, I've used Apache. It's still something of a project to do, but RewriteCond and RewriteRule allow for the permutations needed. Apache has some annoying defaults with regards to setting X-Forwarded-* headers which we have to overcome. Apparently setting X-Forwarded-Host and/or X-Forwarded-Server trips up FusionAuth in some way.

However, I think I've got this working (or rather, I've got it working as well as I can see, and my in-development app can log in too). I've raised a PR on fusionauth-contrib: https://github.com/FusionAuth/fusionauth-contrib/pull/2. There may be more edge cases for API users I haven't considered here - comments welcome.

I've had a look at the github issue @dan posted, and in fact a few others. They all seem to be pretty worthwhile. The hoops I've jumped through here are excessive, and the differences in headers set by Nginx and Apache also tripped me up - all stuff that's not clearly documented or described in FusionAuth. There's definitely something to do here that would really help all of this. I'm not yet sure if the existing issues will solve this, or if another needs raising.

Either way, I hope my PR will save someone else the 1-2 days I've spent hacking about with this!? Thanks all for your help getting this far.

Alex Patterson

As of July 25, 2023 we now support Unlimited Custom Domains for FusionAuth Cloud! You can read more in this post, on how to add a custom domain.