Is there any way to unify users across all tenants?

[willnationsdev]

Problem:

Right now, users of our multi-tenant system must separately log in to each of the tenants we have (and the average user might need access to an arbitrary number of them). We have an ExternalLoginProvider that is shared across tenants to help speed things up, but that still means that separate User accounts are created in each tenant and have to be synced up by username or email and then verified with the external auth. This leads to a tedious user experience, slows down tenant creation, and complicates the centralization of user permissions.

Goals:

• When users log in to one tenant, they will immediately also find themselves logged into other tenants.
• When I create a new tenant with my user account, that same user is automatically set as the new tenant's administrator without manually entering any information.
• I can centrally manage user permissions from the Default tenant and have it impact all other tenants.

[jptissot]

Hi, I have a very similar use-case. I am also trying to build a system that uses multi tenancy where users would only authenticate on the main tenant using the OpenID client / server. I started building a SaaS configuration module to try to easily manage the configuration for all these tenants from the default tenant.

My goal was to:

• Automatically configure the OpenId Server / clients
• Have the ability to set some settings for all child tenants (such as the role mapping script, or maybe manage user permissions)
• Have a user profile that is hosted in the default tenant that is shared between tenants.

The module is not complete but is a good starting point (I think) to manage configuration across tenants.

[willnationsdev]

Hmm. Looking at this module, it looks like the implementation thus far, and the roadmap, is all about duplicating various settings between the tenants and then letting them use those settings to decide to communicate with the default tenant. I have something similar to that myself, and it's working well enough. However, when it comes time to actually work with users/roles/permissions, a different method is needed.

Is it possible to override which services non-Default tenants fetch for a specified collection of services? Things like UserStore, UserManager<IUser>, RoleManager, etc. Perhaps if a module were to register such a service immediately after the OrchardCore versions of said services (in order to override them)? If so, then we might be able to fetch such services from the Default tenant and re-register them, thus subverting the need to copy data between N client tenants at all times.

[jptissot]

I can't seem to find it, but there is an issue in this repository that highlights the different login scenarios that OC might support. One of them being users and roles would come from an external service. Maybe someone else remembers where this issue is located.

[jptissot]

Hmm. Looking at this module, it looks like the implementation thus far, and the roadmap, is all about duplicating various settings between the tenants and then letting them use those settings to decide to communicate with the default tenant. I have something similar to that myself, and it's working well enough. However, when it comes time to actually work with users/roles/permissions, a different method is needed.

Yes, exactly. It is indeed syncing various settings. I also wanted to sync user roles across tenants (for some of the tenants not all) but did not get to it yet.

[yassinsayed]

we are looking to unify users across all tenants. is there any support and feedback

[ns8482e]

Federate using Open ID

[willnationsdev]

There isn't really an officially defined way to do it. You just have to suffer with every tenant having their own independent user accounts.

I believe the only way to get around this would be to directly replace the implementation of the IUserRoleStore<IUser> (I think?) so that OC's UserManager<IUser> service (and therefore also its IUserService service) would seamlessly switch over to whatever persistence mechanism you implement. Your alternative class could then re-use the existing implementation, but fetch it from the Default tenant rather than from the local tenant. That, in turn, would centralize the actual storage of the users (no longer creating a duplicate for each tenant). However, in my investigation of the source code, I judged that it was simply too precarious to risk for the following reasons:

1. There's nothing stopping another plugin from just directly attempting to access IUser documents from the YesSql.ISession instance (all of which would always return false), and trying to hack into THAT process would be much more invasive than anything else you could do. At that point, you might as well just be changing out the entirety of Orchard Core's backend and customizing it to suit your own needs. But doing that would also severely break any compatibility with receiving community updates and maintenance over time, so it's a no-go.
2. Even if you do centrally store users, each individual tenant still has its own IDataProtectionProvider which uses a tenant-specific encryption key, so each tenant's attempts at encrypting/decrypting passwords for that one user would come back with different results and would therefore be unsafe to begin with unless you completely unify all data protection logic for the entire application. I think there was a Secrets module proposed to do that at one point, but idk if it's been merged or not, nor am I sure it would even be a wise consideration given how much it changes just to be able to accommodate the user synchronization.

Ultimately, we opted to simply deal with the duplicates and use AzureAD for logins on each of the tenants (which is a major headache any time we want to add a tenant since we have to configure it in AzureAD and wait for AzureAD to suddenly sync data everywhere and recognize that our tenant is legitimate). We then set up a local data warehouse for aggregating all the Identity data, started working on a custom Feature with a BackgroundTask that pulls data from the warehouse, and then uses it to sync the local tenant's users/roles to match. Still don't have it quite working properly yet, but yeah, it's been as much of a pain in the butt as it sounds.

[ns8482e]

Orchard Core's multi tenancy feature creates different tenants - they are truly isolated in nature and they don't share data, services, users. They are just like any other independent websites - separated by different host names ( or different request URL prefix if using same host-name)

If your need to share users between these tenant websites - then Open ID is the way to go as it's truly allows you to have federated identity, that allows authorized users to access multiple applications and domains using a single set of credentials.

Using Open ID Server feature - you can setup one of Orchard Core tenant to act as identity provider for your other tenants.
Using Open ID Client feature - you can federate to orchard core identity tenant or to external identity provider like Azure AD, Facebook, Github, Amazon Cognito.

[yassinsayed]

I full agree and it is my preferred goal, I tried but did’t work with me my, my i missed up in the configuration, I will be glad and thank full if you share, help with how to do