We have a use case where same users access information in multiple tenants. Is it possible to move the tenant selection after login. Users able to access only tenants they have access to. Do you have any recommendation on how we should handle this.
3 Answer(s)
-
0
Hi @ashgadala
I think you can modify the Login page's server side code and check AbpUserAccounts table with the given username before login operation.
- Then, if there is 1 record, you can directly login the user and do nothing.
- If there are more than 1 records, you can redirect user to a new page you will develop for tenant selection. When user selects the tenant, you can login the user.
-
0
Hi @ashgadala
I think you can modify the Login page's server side code and check AbpUserAccounts table with the given username before login operation.
- Then, if there is 1 record, you can directly login the user and do nothing.
- If there are more than 1 records, you can redirect user to a new page you will develop for tenant selection. When user selects the tenant, you can login the user.
Hi @ismcagdas - we had a similar use case in our angular solution and implemented this client side. Basically a pre-login component that detects multiple tenant "possibilities" based on username/email. If so, a tenant selection modal pops-up otherwise routes to the standard login. What are the advantages of server versus client based approaches?
-
0
We had a similar situation, on an internal application to manage specific customer transactions, where each customer has it's own tenant.
Our solution was to enable multitenancy, but update the login page to hide the tenant selector. All users logged into host instance via LDAP, with almost no privileges (except for admin level accounts).
We added custom permissions for teach tenant that were assignable to host users to specify what tenant each user has access to.
We set up a dashboard widget that displayed an icon for each tenant filtered by access.
On tenant selection, we check if the current user (by email) is in the target tenant users table. if not we create the user and assign it it the default "users" group in the tenant (additional access is manually configured by tenant administrators). Then we use a new method (slightly modified version of impersonation logic) to impersonate the users tenant user.
We also added a button in the tenant's header that takes (stops impersonation) them back to the tenant selection dashboard widget.
Not sure if this is the best way to handle this, but it is working for us.
