On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon <[email protected]> 
wrote: 
> >  I configure CN as the display name attribute. But display
> > names are not unique. So it's not possible to find the right user.

> 
> It's true that display names are not unique. But would it help to number 
> them? You would end up with
> John Doe
> John Doe (2)
> John Doe (3)
> 
> → i see the problem, but forcing unqiueness for display names does not 
> look like a solution for me
> 
> A way would be to add an (optional) second attribute that may be 
> displayed in brackets, e.g. displayName + mail
> John Doe ([email protected])
> John Doe ([email protected])
> 
> I am open for ideas and suggestions on this.

I can understand the desire to keeps things simple and general by not enforcing 
uniqueness of display names, but your own example illustrates the need for 
human-readable, unique identifiers. If all users data is coming from the same 
source, e.g. a single LDAP server, then it is possible to guarantee uniqueness 
by selecting an appropriate attribute. In such a scenario, the email address is 
probably the best choice for the display name.

The problems start once you combine different user bases with duplicate 
attributes values, or once you permit users to change their display names, 
because either one can lead to name clashes. Editable display names are 
especially problematic from a security standpoint, since some users may 
intentionally try to change their display name, in the hope of being mistakenly 
granted access to private data. I used to think that just checking for existing 
display names would be enough to prevent problems, but users may try to grab 
the default display name (e.g. the email address) of a potential user who does 
not have an OC account, yet, creating trouble down the road.

So, for highest security, display names should be globally unique and 
unchangeable.

If that is not the case, then we have to rely on the suggested displayName + 
mail, which effectively creates a third user identifier, let's call this the 
unique display name (UDN). Due to the mentioned security issues, the UDN should 
be used pretty much everywhere instead of the simple display name, which makes 
the non-unique display name superfluous.

Considering the display name just as the editable part of the UDN, without ever 
using it on its own, would require extensive code changes but seems like  a 
reasonable compromise.

BTW thank you Arthur for answering my other mail.

Cheers
Andreas
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud

Reply via email to