Shared Users

john.porter

Here's an interesting use case that I can't figure out how to solve and would like some advice for...

We have ClientA, ClientB and Internal. Each of these has separate Users.

We have one product that we provide as a company, which has a central API and UIs hosted at different URIs (one for ClientA and one for ClientB), each connects to a central API (very simple multitenancy).

All good so far

ClientA, ClientB each have separate password strength requirements etc. They all want to be able to log in to their own configured UI.

Out Internal Users must be able to connect to each separate UI as themselves using the same login credentials, as long as they have permission to do so (This is where I am stuck).

I hope this is clear so far. So the thoughts I've had are to have three Tenants, one for each Client and Internal. Each UI is an Application within the relevant Tenant, and the API is an Application within Internal Tenant (I think??).

I can clearly authenticate a login to the right UI under each Tenant, but how do I allow Internal to log in to the other UIs? How do I verify a login from multiple Tenants as being allowed to access the API if that is in a different Tenant?

The clear requirement I have been given is that our Internal users must not have to have separate passwords for each UI, and that we would prefer to not have to configure separate Applications for each Client.

Would anyone have any suggestions on how I can achieve this?

joshua

@john-porter,

You are on the right track to consider using tenants. You may want to consult some of our information on tenants here.

I am not sure I have a clear path for you to follow to implement a quick solution. Certainly a combination of:

roles, - to limit who gets to do what
groups, - to delineate clients and other logical groupings
and tenants

will get you somewhat close to what you are seeking. Of course, you could use our API and the above three concepts to hand-roll your own UI to possibly better fit your business needs.

If you need a deeper dive on this issue you could consider getting a support plan (no pressure, just an option if needed).

I hope this offers some guidance. If I have any other thoughts I will let you know! Good luck!

Thanks,
Josh

joshua

@john-porter

My colleague offered up two more concrete solutions:

Webhook on change to user in one tenant triggers lookup, delete and re-import of that user into all other platforms. There is no great way to get the password hash, though. If internal users want to be able to change their password, you would need a separate password hashing page. Thus, this solution is workable but, not the most glued-together and may present more challenges than solutions in the long run.
Use a managed domain (for all their internal users) and a federated IdP (another FusionAuth instance for example). Remove the buttons from the UX*, but use the IdP hint parameter and provide a special login link to internal users which always pushes them to that IdP. Enable this IdP for all applications across all tenants. The internal users then have one password managed at the 'internal IdP'.

With either option you would have internal users that have access to all tenants/applications with the same password without having to do any "manual syncing steps."

I hope this helps and gives you some considerations moving forward!

Thanks,
Josh

*When you add an Identity Provider to a FusionAuth application, it automatically adds the 'login with <idp>' button to the login page. Since this IdP will only be used by internal users, for whom a URL can be provided, we don't want to display that button (to regular users).

john.porter

Hi Joshua,

I think option 2 is what I was thinking. When you say another FusionAuth instance, can I assume it could very well be a tenant on the same instance? So, loop back to itself using a tenant ID?

joshua

@john-porter

Another instance of FusionAuth would be another running instance of FusionAuth on a separate server connecting via option 2 (federated).

I will have to check and see if it is possible to do it on the same instance under a different tenant. Part of me thinks it should be possible. I will let you know if I get confirmation left or right of this question.

Thanks,
Josh

utahtwo

@joshua Did you ever confirm this? I have the exact same scenario. I was thinking about adding an identity provider (SAML) that is itself (same fusion instance). Then like mentioned have a separate login for internal users, like /internal that kicks off the login with that IDp.

dan

@utahtwo I tried that and was unable to make it work a few months back. @joshua filed an issue here: https://github.com/FusionAuth/fusionauth-issues/issues/1532

The simplest solution if you are self hosting is to run a different instance of FusionAuth on a different port against a different database. I've done that successfully.