Allow same user.login for different tenant

Add-ons
#1

Hi.
I suppose to run my app for 3 different legal entities. each legal entity is a totally different brand.
So one user can join these 3 websites without knowing that they are under the same app (as planned).
I want to be able to register the same user.login on all tenants. the problem becomes even harder because we use the email as the login.
So the message username already exist is not relevant.

Thanks

#2

Hi Avi,
Are you using the multi-tenancy add-on?

#3

Yes. I am talking about the multi tenancy plugun

#4

OK. If the login name is the same, how the user will choose the tenant he wants to log in? By selecting in a UI control on the login screen?

#5

This is the site login.
I am sending the tenant from the client side.
Imagine I have two websites.
tables.com
Chairs.com
Same backend, tenant per domain.
Each website will send the tenant id in every request.
So theoretically, one user can be in two websites.
Not even knowing they are related.

Actually it’s not theoretically, from my experience, 3 percent will be registered on both we sites.
Thanks

#6

Selection of the tenant in the login UI would solve my usecase - Preferably the available tenants to choose from, should only be ones which the user has access to

#7

I don’t think you understand my use-case. your use-case is perfectly understood. but its easy.

The whole idea behind multi-tenancy is that the same backend may serve several different (legal) entities. different entities that may not know about each other. “software as a service”.

I, as a b2b software provider, want to give the possibility for my clients to onboard to their website whoever they want to.
So,

a.com
b.com
c.com

are tenants, one is selling books, one is selling T-shirts and one is selling phones.
there are times when one user register to buy a book in a.com, and after a month he sees an advertisement to b.com and wants to buy a phone.
Since the user.login is unique per database and not per tenant, he cannot register to b.com because he is already a user who registered a month a go in a.com on the Cuba platform. so my client will lose customers because someone already registered them to their tenant.

this is how my users table may be look like:

+---------------+-----------+---------------+  
| login         | tenant_id | email         |
+---------------+-----------+---------------+
| one@gmail.com | a.com     | one@gmail.com |
+---------------+-----------+---------------+
| one@gmail.com | b.com     | one@gmail.com |
+---------------+-----------+---------------+
| one@gmail.com | c.com     | one@gmail.com |
+---------------+-----------+---------------+

The uniqueness is login,tenant_id and not just login or email.

Or, I am missing something here and the tenant is really distinguishing tenant at the user level but somehow its not working for me…

I really hope you git me this time (-:
Thanks

#8

If tenant is known when the user is logging in, it can be used for authentication together with login name. So you need to create a set of Credentials/LoginProvider/AuthenticationProvider which will consider the tenantId, see Web Login and Login. Also, the database unique constraint on the login field must be re-created to include tenantId.

I’ve created an issue for the add-on, we’ll consider implementing it as a feature.

#9

Ok. yes, the tenant is known,
But im using Cuba rest default login/token.
Do you have an example project how can I expose my own login mechanism in my rest service?
Thanks

#13

Hi,
We don’t have example of this, but you can try the following. A place where authentication is performed is the com.haulmont.restapi.auth.CubaUserAuthenticationProvider class. You can override this bean (the bean id is userAuthenticationProvider, it is registered in the cuba-rest-dispatcher-spring.xml). In you implementation you’ll have access to all additional parameters passed in the access token request (not only grant_type, username and password, but also a tenant_id for example). Then after you have both username and tenantId you can do an authentication in a way you need. Keep in mind, that this bean should be registered in your own rest-dispatcher-spring.xml file.

#15

Hi,

You could also store in the login field a combined text of tenantId + “/“ + email. If you control the rest client users, then you can send it accordingly.

Then most (if not all) of the problems go away…

Bye
Mario

1 Like