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.

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

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).

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.

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.