[Owncloud] owncloud alpha 1 and LDAP entryUUID

[Arthur Schiwon]

On 02/19/2013 02:55 PM, Andreas Ergenzinger wrote:
>
> On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon <blizzz at owncloud.com> 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 (john at doe.net)
>> John Doe (john.doe at example.biz)
>>
>> 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.

Depends on where you tackle it. If you ensure uniqueness on LDAP side, 
you are not getting a problem on ownCloud as long as you don't use other 
user backends (which may have other problems). In some cases it is 
necessary that display names can be modified, for instance when family 
names change, titles needs to be added, or if job positions, departments 
or likes are included in the display name.

When you take a step back and look at a bigger picture, some backends do 
not provide user lists (IMAP, WebDAV) so you cannot see which names are 
already in use. Shifting it all to ownCloud core means drawbacks as 
stated above.

The LDAP backend really takes care that _internal_ names stay unique. As 
it was up to 4.5 they also were used as display names which did not make 
all people happy, because of the limitations.

Note that not every available user backend takes care of unique names 
(ownCloud's internal does, IMAP or WebDAV don't afaik).

Also note that display names of LDAP users cannot be changed from within 
ownCloud as we do not write to LDAP.

> 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.

The LDAP configuration gives you pretty much free hand of what you 
define as display name. Take an exisiting attribute of your choice or 
extend you directory with one. It gives you a lot of power and flexibility.


> BTW thank you Arthur for answering my other mail.

Welcome

Cheers
Arthur

>
> Cheers
> Andreas
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>