glpi 0.72 architecture problem with entities

linvinus · 2009-08-19 13:53:08

User login should not be unique in sql user table.
Because same login could be in multiply entities .

for example:
admin@parent.domain
and admin@child.parent.domain

Glpi should identify user by login and entity, or by email.

Also when importing users from ldap, should be option in to which entity import.

When importing computers from OCS
glpi could compare ocs.machine.domain_name with entity, through special rule, then search osc.login + entity in glpi_users table.

Last edited by linvinus (2009-08-19 13:56:23)

remi · 2009-08-19 14:16:02

> User login should not be unique in sql user table.
Login must be unique by design.

There is a ticket (somewhere in the roadmap) to store domain with username.

> Also when importing users from ldap, should be option in to which entity import.
No. User are not imported in 1 entity.
Entity are defined in the right of the user (user/profil relation)

+

linvinus · 2009-08-19 14:39:22

remi,
>There is a ticket (somewhere in the roadmap) to store domain with username.
then,probably, better use unique email instead login. Because it is login+domain and also unique criteria in help-desk.

Last edited by linvinus (2009-08-19 14:41:08)

wawa · 2009-08-19 14:41:27

linvinus wrote:

then,probably, better use email . Because it is login+domain and also unique criteria in help-desk.

and what if I don't use helpdesk and I don't have email in my ldap directory ?

everybody can choose the login he wants, and for now login must be unique.

linvinus · 2009-08-19 15:26:03

wawa wrote:

linvinus wrote:
then,probably, better use email . Because it is login+domain and also unique criteria in help-desk.
and what if I don't use helpdesk and I don't have email in my ldap directory ?
everybody can choose the login he wants, and for now login must be unique.

ok, email as id looks not so good. (even glpi will generate unique email if user don't have email in ldap)

But what we will do when will track ticket by email, if we will use domain+login as unique user id.
In this situation we also will have variant when different users can have same email.

My problem is that i have one physical entity but with two email-domains.
For now i can't automatically track tickets from both domains. Because i can't create another user with same login, or add another email for same user.

Also this problem can appear when user send email from public email server (for example gmail.com)

gaio · 2009-10-01 14:39:10

remi wrote:

Login must be unique by design.

You just have the account/user ID as unique filed, why not simply use it? Why use the login? Seems to me 'broken by design'...

remi wrote:

There is a ticket (somewhere in the roadmap) to store domain with username.

Some idea when this will be implemented?

Apart of the 'new feature' part, in this subject there's also a terrible BUG 'embedded': if i use more than one auth provider (for me, 3 LDAP servers) and in the providers different users with the same login exist, one user can impersonate another one, because GLPI query the auth provider in turn, and assign credential to the first that authenticate correctly.

This is indeed a SECURITY BUG, and have at least to be mitigated (eg: query the auth provider in turn and if user exist and login fail, stop query and return error).

wawa · 2009-10-01 14:46:08

gaio wrote:

remi wrote:
Login must be unique by design.
You just have the account/user ID as unique filed, why not simply use it? Why use the login? Seems to me 'broken by design'...

I don't understand whatdo you propose ?

gaio wrote:

Apart of the 'new feature' part, in this subject there's also a terrible BUG 'embedded': if i use more than one auth provider (for me, 3 LDAP servers) and in the providers different users with the same login exist, one user can impersonate another one, because GLPI query the auth provider in turn, and assign credential to the first that authenticate correctly.
This is indeed a SECURITY BUG, and have at least to be mitigated (eg: query the auth provider in turn and if user exist and login fail, stop query and return error).

no it's not a security bug, it's the way it has been implemented and the way we've designed it
once again, for now : the login field must be unique

gaio · 2009-10-01 15:16:08

wawa wrote:

I don't understand whatdo you propose ?

in glpi_users there's the 'name' field (login) but also an 'ID' field: i understand that 'ID' field have to be unique, but really i don't understand because the 'name' field have too...

wawa wrote:

no it's not a security bug, it's the way it has been implemented and the way we've designed it

Ok, i've understood that is designed in this way, but this is really na security bug; mind only if in one auth provider there's an user 'john' with administrative rights granted, and in another auth provoder a different 'john' user that have not: even the second unprivileged user if login, got administrative rights!

This IS a security bug...

Forum GLPI-Project

Announcement

#1 2009-08-19 13:53:08

glpi 0.72 architecture problem with entities

#2 2009-08-19 14:16:02

Re: glpi 0.72 architecture problem with entities

#3 2009-08-19 14:39:22

Re: glpi 0.72 architecture problem with entities

#4 2009-08-19 14:41:27

Re: glpi 0.72 architecture problem with entities

#5 2009-08-19 15:26:03

Re: glpi 0.72 architecture problem with entities

#6 2009-10-01 14:39:10

Re: glpi 0.72 architecture problem with entities

#7 2009-10-01 14:46:08

Re: glpi 0.72 architecture problem with entities

#8 2009-10-01 15:16:08

Re: glpi 0.72 architecture problem with entities

Board footer