Facilitate changing client for users with multiple access

188 views
Skip to first unread message

Nicolas Micoud

unread,
Jul 7, 2014, 6:53:03 AM7/7/14
to idem...@googlegroups.com
Hi,

In our production environnment, we have a customer who works on several AD_Client (5)
And some of the users must have access to 3, 4 or 5 clients.
I have created 5 records in AD_User, and each records has same login and password.

When login for the first time of the day, he can choose the society and the role.
But when he wants to change society, he has to log out and write again his password, check 'Select Role', click on OK, select the correct society and then proceed.

With SuperUser, i can do the same just by clicking on 'Change Role'.

I would like to have same behaviour for non System users.
Means that when arriving on the 'Choose Role/Society/...' panel, show the AD_Client list if the current username/password is created more than once.
Can it be considered as a common requirement or do you think that could lead to a security problem ?

WDYT ?

Regards,

Nicolas

norber...@multimageweb.com

unread,
Jul 7, 2014, 8:24:38 AM7/7/14
to idem...@googlegroups.com
Hi Nicolas, 

We had the same discussion with @michal here few weeks ago :) i met this already with another proprietary ERP. There was something like Global Users feature. 

Functional overview (try to describe the same in idempiere language) how should works: 

SuperUser able to define in System Client - "Global Users" in Global User Window. Admin add new global user, selects Users from list of users (ad_user) and in related tab define clients per line. This global user has own role in master record but also each clients has own security role in defined in details (so user theoretically can login to each client with another access right)

example:
master record:
Global User
Selected User: NMI
Global role: Accountant

line: 
client 1 Role: assistant
client 2 Role: no role
client 3 Role: Accountant


hope my experience help  :) i vote +1 for similar solution.

norbert

This e-mail is confidential and may contain legally privileged information. It is intended only for the addressees and may not be reviewed or used in any way by other recipients. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message and any attachments thereto from your system.

Hiep Lq

unread,
Jul 7, 2014, 9:46:04 AM7/7/14
to idem...@googlegroups.com
Norbert.
what is difference of Global Users and a user in system client have role in other client (i mean same current super user).
if just relate to role in multi client, user in system client can help.


@Nicolas. if you implement this request. please consider some issue

Carlos Antonio Ruiz Gomez

unread,
Jul 7, 2014, 11:22:29 AM7/7/14
to idem...@googlegroups.com
Nicolas,

I'm trying to remember why we made this design decision, and if I don't recall wrongly I think it was because using hashed passwords (which is the recommendation for any production system) you cannot check if the password is the same on the other tenants.

Regards,

Carlos Ruiz

Nicolas Micoud

unread,
Jul 7, 2014, 1:59:01 PM7/7/14
to idem...@googlegroups.com
That's a good reason :)

What could be done ? Add a kind of clone number on AD_User to make link between those records ? Or create a new table as Norbert suggested ?
Or is it considered as a very specific need and won't be handled in core ?

Thanks,

Nicolas

Carlos Antonio Ruiz Gomez

unread,
Jul 7, 2014, 2:36:27 PM7/7/14
to idem...@googlegroups.com
I tend to think that given the easy workaround (login again) and the number of users affected (a minority IMHO) it's not worthy to open possible security issues.

Regards,

Carlos Ruiz

Nicolas Micoud

unread,
Jul 8, 2014, 3:47:26 AM7/8/14
to idem...@googlegroups.com
ok, thanks,

Regards,

Nicolas

norber...@multimageweb.com

unread,
Jul 8, 2014, 4:51:00 AM7/8/14
to idem...@googlegroups.com
Carlos, 

i understand, and trust you about security notes. Just an idea, what about create a new table for storing passwords per user and client (deactivate existing passw. field) ? e.g. (ad_passwords) columns should be: client_id, user_id, password. when password changed for a "global user" will be changed for all clients separately - hashed separately per client.  Important, user will be same. it is similar like in bitckucket 1 user@ across multiple repositories, with multiple security tokens.

related to my personal opinion: i had use cases, where reason for new deal was client data and user sharing. for me looks important factor. but it is my private one.

i believe i'm not wrote technical stupidity or nonsense :)  

n

Carlos Antonio Ruiz Gomez

unread,
Jul 8, 2014, 3:25:26 PM7/8/14
to idem...@googlegroups.com
As Nicolas pointed, a possible approach could be to add a column AD_User.LinkedUser_ID as advanced showing just system users.

If you want global users you create the global user on System, and the client user on each tenant and use the new field to link them.

The code could be changed to set the password just on the global user (on system) in such case.

It doesn't sound easy, but also it doesn't sound hard or too disruptive.

Regards,

Carlos Ruiz

Deepak Pansheriya (Logilite.com)

unread,
Jul 10, 2014, 3:19:36 AM7/10/14
to idem...@googlegroups.com
Carlos,
We can add model after save logic on user to check if 2 client has user with password and role and having same email address then system auto create users in system and add linking. If client on user is linked to system user then password update directly reflected on System user.
At login time, system always check for sytem user first and then it try to check for other tenant user.

Carlos Antonio Ruiz Gomez

unread,
Jul 10, 2014, 11:38:27 AM7/10/14
to idem...@googlegroups.com
Yep, but I remember we wanted to support also the case where a multi-tenant user has different passwords per tenant (not sure if is worthy, just when we discussed it we wanted to support this case).

Note also in principle the multi-password is supported, but if any of the passwords expires or forgotten all passwords are synchronized by reset password.

So, maybe is OK to reconsider if we want to keep supporting the multi-password approach, if not then what Deepak suggest is easier.

Regards,

Carlos Ruiz

Nicolas Micoud

unread,
Jul 10, 2014, 4:54:35 PM7/10/14
to idem...@googlegroups.com
I don't see the interest of multi password ; it's just for synchronizing fields like name, phone, email ?

Thanks,

Nicolas 

Deepak Pansheriya (Logilite.com)

unread,
Jul 11, 2014, 2:06:16 AM7/11/14
to idem...@googlegroups.com

I strongly believe that if we want to offer single password for all client, user must be linked by email address. There may be chance that 2 tenant has 2 different user with same name. But those are 2 different users. Email address is actual identity to differentiate between actual users.

Nicolas Micoud

unread,
Jul 11, 2014, 2:17:41 AM7/11/14
to idem...@googlegroups.com
Not sure. For instance, in my case, there are 5 differents societies (AD_Client).
Each user has same name, but email adresse will be different (eg. john...@client1.com, john...@client2.com, ...).
I think the email adress could be used in maybe 90%, but i think a manual confirmation is needed, as it could create security breach.
WDYT?

Heng Sin Low

unread,
Jul 11, 2014, 3:40:21 AM7/11/14
to idem...@googlegroups.com
One option is to let the user to link his/her accounts together. The idea is the user will login to his main account, navigate to the user profile page and add the linkage to the user's other account for other tenant ( probably should be a process that the user have to enter the user name and password for other account that the user wants to add linkage to the main user account ).


--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/0e56d4b3-37b2-44aa-ba0c-745ebcc939c9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages