[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Dynamic group draft
One of the use-cases of dynamic group is to set a dynamic group as an ACL Trustee for a resource. For use in this situation, using the user's identity could be a problem with respect to both security and consistency. Imagine a case where a deny ACL is set using the dynamic group as a trustee with the expectation that the members of the dynamic group will match that. Now if the members get limited by the user's search rights, then an access could be granted where it should have not been. Using a separate identity (eg. dgIdentity) builds consistency and predictability into the dynamic group member list.
imho the members of a dynamic group should be based on the intention of the administrator - not based on the rights of the user. However who can read the dynamic group attributes can be limited by the ACLs on the DG object.
Thanks and Regards,
Haripriya
>>> Pierangelo Masarati <ando@sys-net.it> 02/10/07 2:44 AM >>>
Howard Chu wrote:
> http://www.ietf.org/internet- drafts/draft- haripriya- dynamicgroup- 02.txt
>
> It's funny that this has come up since we've been having discussions of
> these same points on the OpenLDAP- Devel mailing list recently. I hadn't
> seen any prior versions of this draft before, can you point me to a
> forum where it had been discussed?
One point that puzzles me is a security concern, which was extensively
discussed about OpenLDAP's slapo- dynlist(5) overlay
<http://www.openldap.org/lists/openldap- devel/200701/msg00038.html>
which basically deals with the identity that must be used to perform the
internal search to collect the dynamic group. In dynlist's case things
are complicated by the fact that attributes of the entries matching the
search need to be collected, but the problem is the same.
If I understand that draft correctly, internal searches are either
performed anonymously, or, if dgIdentity is present, using that
identity. The rationale is that using any other identity, and
significantly that of the operation accessing the dynamic group, would
lead to identity- dependent group membership.
I understand data uniformity in some cases may be an issue, but it seems
to me (as I argumented in that discussion) that this could either (a)
break security or (b) lead to other inconsistencies; for example:
(a) Using dgIdentity could break security if a user with privileges that
do not allow disclosure of the existence of a certain DN reads or
compares a dynamic group that discloses that information.
(b) Using anonymous, or even dgIdentity, could lead to inconsistencies
if a user is granted permission access the results of a search defined
as the memberQueryURL of a dynamic group, but neither anonymous nor the
dgIdentity have such privileges (this is a minor issue, though).
For this reason, although we planned to introduce something like
dgIdentity in slapo- dynlist(5), I believe that a safer and more
consistent solution would be to change the specification so that:
1) in case a dgIdentity is defined, it MUST be used to perform the
internal operations; if it's set to the empty DN (""), internal
operations are performed anonymously. Implementations may use access
control to determine whether a user is allowed to access, and thus
assume, dgIdentity to perform the internal operations;
2) otherwise searches and operations are performed with the user's identity
In slapo- dynlist(5) we also discussed the opportunity to introduce some
sort of authorization (along the lines of the authzFrom operational
attribute used for authorization) to determine whether a certain user is
allowed to perform internal operations using OpenLDAP's equivalent of
the dgIdentity. Nothing of this is implemented yet.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys- net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys- net.it
------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext