Thanks @Heng Sin Low - answering your points:

about 1. a Google search seems to show that is not rare, there are a lot of results showing people with the same need and some systems implement it while others don’t.
Also found this is directly related too to the problem we have with SSO, if the email is unique through the whole system, then we don’t have the SSO problem that we need to identify the tenant beforehand. Support for “same user multiple tenants” makes it harder, but I think removing that feature can go against the usability, for example in Colombia and Germany is very common that the same accountant or tax advisor serves many companies, and would be very difficult to ask to use a different email on every company.

about 2. there can be cases where the password policies cannot be mixed, f.e. one company defining minimum length password of 8 and another company defining maximum length password of 7 (corner case, but just an example to illustrate that policies can be incompatible)

about 3. maybe this would be easiest way to implement this, we can support “same user multiple tenants”, but when doing a password change or reset we do not support spreading the password change over users with different policy (this sounds going against user experience, but would work)

Now, thinking deeper about this, from a security point of view I think this ticket is not good.

My opinion is that the password policy must be set by the SaaS provider (f.e. devcoffee), and allowing each tenant to define their own policy will make the whole system weaker, less safe.

Suppose the SaaS provider wants a strict password policy - because they are concerned about security and the website can be exposed. But one tenant implements a very lazy password policy, easy to break in, a hacker can attack that single tenant, get access to the system, and potentially exploit the system to get access to the other tenants that are more secure (f.e. that’s easily possible with a bad management of Advanced Roles)

Another point of view, I remember @Steven-Adaxa mentioned to me a couple of times, in the case of a security leak the SaaS provider (or the software provider) must be able to prove due diligence to avoid being sued, a weak password policy can be interpreted as a lack of due diligence.

Having said that, I prefer to vote against this change.

My take on this:

1. Same user for multiple tenant is indeed rare in SaaS environment, perhaps we can add system configuration entry to make that optional (would need to enforce that the login identity (email or user name) is unique across the system),

2. It is possible to support both tenant level password policy and same user across tenant - would have to modify the change password process to validate new password against all applicable password policy.

3. Alternative way to support 1 user for multiple tenant is to do it similar to the GMail approach where user would explicitly add authentication profile for other tenant and application should provide support to switch to another tenant using the explicitly added authentication profile.

@Carlos Ruiz I think supporting single username with multiple tenant needs to supported. this is required when a group of companies using shared server.

I suggest that if even if this needs to compromise, it should be system configurable so that either of per tenant password policy or same user for multiple tenant can be opted.

Hi @Jose Leite / @Murilo Habermann Torquato

I remember initially this was designed as multi-tenant, but then - for some reason - we changed our mind and made it system wide with this commit https://github.com/idempiere/idempiere/commit/9735670208f6d8066b8347f4551fe7f782f2c161

I don’t remember exactly what was the reason.

Thinking about that, most probably we found problems when we designed to support an email having users in several tenants and all of them can act as one user if they have the same password, the “Forgot my password” and “Reset password” function needs to validate the password using a set of rules, but in the case of same user in multiple tenants, then the password could be subject to several policies.

Maybe there are other functions that are affected by this, but I don’t remember and I didn’t find documented the reason of the change.

I think maybe it could be possible to support this (password policy by tenant) but then the support for same user in multiple tenants must be reconsidered, in such case the “Forgot my password” / “Reset password” would need to manage the users as separate entities?

WDYT?

cc: @Heng Sin Low / @Deepak Pansheriya / @Norbert Bede