We want to remove the tenant selector from the login screen so have been following this guide https://docs.aspnetzero.com/aspnet-core-angular/latest/Core-Angular-Sign-In-Without-Specifying-Tenant
Can you confirm this code is still correct for v14.1?
Also, not all users will have unique email addresses, which is a problem with this example. We have previously used are own approach to this, splitting the dbContext so that all user, role and permission data stays in the Host Database and when a new user is created with an existing email address, we "Link" the users and then keep them in sync, e.g. user changes their password, it changes for ALL users with the same email address. Same for Name, Photo etc. I think this was a bad idea as Tenants can create users with the same email address and then change the password which then syncs. The only thing stopping them from logging in to access their data is the Email Verification which doesn't seem secure enough.
Is anyone else implementing similar functionality? No Tenant Selector but non unique email addresses? Keen to find a better solution. We have considered using domain names to select the tenant but our users have previously told us they don't like this approach as we have 100s of tenants, some with similar names so the URLs become hard to remember
5 Answer(s)
-
0
Hi @4Matrix
The document you referenced is currently outdated and not fully compatible with ASP.NET Zero v14.1. There have been some changes in the login flow and tenant resolution mechanism in the latest version, so the approach described in the guide may not work as-is. We recommend reviewing the latest release notes and the sample project for up-to-date guidance.
Additionally, creating and synchronizing users with the same email address across multiple tenants poses risks in terms of security and data integrity. The most secure approach is to enforce unique email addresses per tenant. Alternatively, you can design a system that enforces uniqueness using a combination of Username + Tenant.
In such cases, applying a unique indexing strategy (e.g., Email + TenantId) for each user can enhance security and prevent users from accessing each other’s data.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi, we are revisiting this issue again. I can see that using the default setup, Even if each tenant has their own database, the AbpUserAccounts table always contains a list of ALL users in ALL tenants with their non unique email addresses, which is great. The UserLinkId field seems to no longer be in use, User links are now recorded in the UserAccountLinks table using the ID's from the AbpUserAccounts table, which again is great.
We want to remove as much of our custom logic as possible. We currently store ALL the AspNetZero dbContext tables in the Host database and have a separate tenantDbContext which uses the tenant connection string with each teanant having their own database. This works ok but is not ideal for things like Audit Logs, permissions, roles, settings etc
With the standard aproach, we would have to find ALL instances of that email address in AbpUserAccounts and loop through the matching tenants and try to login but that could be a pretty inefficient process, especially when you add in the possibility of External logins being allowed. I guess we would maybe want to store just the abpUser tables in the "Host" database too but not the others? Any guidance on this or if you have any plans to implement something similar would be of great help
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi @4Matrix
If different users from different tenants might have the same email address, how you want to determine the correct tenant in theory ? We can offer you a solution according to your answer.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi @ismcagdas
I guess we would want either a "Tenant Selector" showing all the tenants they are linked to after login? Possibly with the option of remembering the selection and bypassing this page in future, along with the option of always use the most recently used tenant for that user account. It is tricky as there are other things at play here such as the reset password flow and which tenant/user it would update during that flow. I guess it could update all of them OR just the first one it finds logging in with any combo should allow them to then switch between the tenants. We also need to keep support for External logins for Office 365 and Google accounts. This would be for a global registration though, not per tenant as this could get messy. Our current approach to this is there has to be a user with the matching email address in order to login with External Login
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi @4Matrix
Thank you for the detailed explanation this clarifies the real problem very well.
First, it’s important to be explicit about the core constraint here:
If email addresses are not unique across tenants, then the system must have an explicit tenant resolution step at some point in the authentication flow. There is no fully safe way to infer the correct tenant automatically from email/password alone.
Because of this, any solution without a tenant selector before or after authentication will always be ambiguous by design.
Given this constraint, the safest and simplest approach is to separate authentication from tenant selection:
- Authenticate the user first (email/password or external login)
- Then show a Tenant Selector listing the tenants linked to that account
- Optionally remember the last used tenant
This avoids looping through tenants during login and works with non unique emails and external providers.
For password resets and external logins, the same rule applies: if a user belongs to multiple tenants, an explicit tenant selection step is required.
We do not recommend synchronizing users or credentials across tenants, as this introduces security and maintenance risks. Using the standard tenant isolation model keeps the system predictable and secure.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image)
