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
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
