[Owncloud] Users LDAP storage related issues

[Jeroen van Meeuwen (Kolab Systems)]

Hi Arthur,

I'm getting back to the other points you raised later, but there's one 
that is explicitly a requirement and I somewhat disagree with your line 
of thought on that one.

On 2012-02-29 19:46, Arthur Schiwon wrote:
> On Tuesday 28 February 2012 14:27:36 Aleksander Machniak wrote:
>> - It should use the user's bind credentials, and not the service 
>> bind
>> credentials,
>
> To perform LDAP searches?

To perform any LDAP operation, really.

> For Univention we create an extra LDAP-user who is able to search the 
> LDAP,
> but has no other function.

This is what I would call "service bind credentials". It usually has 
access to the entire tree, but read-only access only. Therein lays part 
of the problem.

> And not always every user is allowed to perform searches.

While this is not exactly the point, it is close to exactly the point 
;-)

> The thing is: we need to store the password in a way that it either 
> can be
> computed back or directly in plain text. Thing is: if someone gets 
> access to
> the machine, he will find out either way.

For service bind credentials, and for "anonymous bind credentials" (not 
the same as an "anonymous bind" if you will), yes, ownCloud 
configuration is supposed to hold these credentials.

> In this case is more to secure not to use user credentials, but to 
> have
> distinct credentials therefore. Even the password can be changed
> every now and then without much trouble.
>
> It is possible to offer the option to use user bind credentials, but
> i really dislike the idea becaues of this.
>

There is something to say for arguing storing a copy of a plaintext 
password in an application's configuration being insecure, but it's a 
necessity in the scenario I'm about to outline.

>> - It attempts to create a full list of usernames for 
>> auto-completion,
>> which it shouldn't do for lists of usernames can get rather large.
>
> Meanwhile, you can specifiy the filter for the user list.
> Still it can become pretty large if there are a lot of users that
> should have access to ownCloud. But you can get rid of unneeded 
> accounts.
>

It should use (if available) auto-completion with Virtual List View 
control.

Please note that this is really advanced stuff. We would be more than 
glad to help you guys out with this stuff, as we've done it before.

The scenario is as follows:

- An LDAP tree contains 500k entries (users, groups, roles, contacts, 
etc.).

Even if someone (users, administrators) or something (service/anonymous 
bind credentials) were allowed to search, the time it takes to get one's 
hands on the results is several minutes.

For listing and searching users, groups, one would use a combination of 
VLV Indexes and Sort controls for each type.

In such a large tree however, you can imagine some users are not 
supposed to have access to list, search, find and/or view details of 
certain parts of the tree.

The methodology we use successfully today (Roundcube) consists of the 
following sequence;

- The user logs in,
- The application uses service bind credentials to search for the 
user's LDAP entry (i.e. a query with a filter similar to something like 
"(|(uid=%u)(mail=%u))"),
- Once the user's entry is found, the application continues to operate 
solely with the user's bind_dn, and the password supplied during login.
- The user's password is saved in a session variable, encrypted using 
another setting in the application's configuration.

This enables the full extent of LDAP Access Control to be applied to 
what the user can actually see and/or find.

The security "concern" here is only justified to a user getting his/her 
hands on service bind credentials, and therefore being able to search 
the entire tree / view details for all entries.

"Anonymous bind credentials" are often used to allow an application to 
use LDAP in the background, without requiring a user to login, exposing 
only those components and entries in the LDAP tree that would be visible 
to anyone anyway.

"Anonymous binds" are different in that anyone can literally bind 
anonymously, something that causes anonymous binds to often not be 
allowed.

I hope this helps in understanding where we're coming from with this.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08