[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Nested group (was: groupOfEntries object class proposal)
This anticipates a reliable mechanism that ensures direct members are not added to the nestedGroups attribute and that nested groups are not inadvertently added to the member attribute. How would the server respond if an object is included in both attributes?
-----Original Message-----
From: simo [mailto:idra@samba.org]
Sent: Wednesday, September 19, 2007 12:42 PM
To: Andrew Findlay
Cc: ldapext@ietf.org; Luke Howard; Steven Legg; Michael Ströder
Subject: Re: [ldapext] Nested group (was: groupOfEntries object class proposal)
On Wed, 2007-09-19 at 16:21 +0100, Andrew Findlay wrote:
> The efficiency gain comes from not having to read the entries of the
> direct members just to find out whether they are actually nested
> groups or not. This could make a massive difference in cases where a
> group has a lot of direct members as well as a few nested groups.
>
> The complexity in determining whether a given DN is a member of
> a potentially-nested group is much the same whether we use 'member'
> for everything or 'member' and 'nestedGroup', but using the two
> different attributes can save a vast number of LDAP operations.
> Consider this algorithm:
>
> IsAMember( subjectDN, groupDN ) {
> Match subjectDN against 'member' attribute of group entry:
> stop if it matches, the DN is a member.
>
> for each nested group {
> if IsAMember( subjectDN, nestedGroupDN )
> then stop, the DN is a member.
> }
>
> The DN is not a member
> }
>
> The first match is a single LDAP search on the basic group entry.
>
> The foreach loop requires one LDAP search on the base, plus:
>
> If we only use 'member' attributes,
> one LDAP search on each member to find out what it is
> before calling the procedure recursively on each nested group.
>
> If we separate direct members from nested groups using
> different attributes, we recurse immediately with no extra
> LDAP ops.
>
> Hmm: I think the different-attributes case is actually *simpler* to
> code. The algorithm for enumerating members is almost identical.
- for each nested group {
+ for each member {
The algorithm complexity is the same, although, it is true, a client may
require more operations.
Actually I think this problem would be better solved by a control to ask
the server to do the calculations for us (and IIRC there is a control
like that in the AD implementation called ASQ or something like that)
and use a cache, so we have both an efficient way to do it and avoid the
artificial distinction.
> This sort of thing has a value in many authorisation cases. Clients
> often need to know 'is this user allowed to do X' where the permission
> is expressed as membership of a group. Nested groups are extremely
> useful in this scenario as you often want one level to classify the
> users by roles and a second level to define what each role is allowed
> to do. The client just wants a yes/no answer and is not often
> interested in which group membership chain actually permitted the
> access. If the server supports server-side nesting then a single LDAP
> search will answer the question.
Yes, true, a control that allow you to do that would be a good thing,
but it is just convenient, not mandatory, doing the "un-rolling" by
default is what I think is bad.
> > It's up to you to use nested groups or not. It's not mandatory, and
> > doing it client side has also benefits.
>
> Indeed, and I would not want to stop anyone doing so.
No doubt :)
> > Suppose I need to check user A is in group A, where group A has 128 sub
> > groups, with others again.
> > Now if you do server side resolution at each query of the member
> > attribute you have to fully unwind all groups every time (sure caching
> > helps), instead if you are a client, you can stop at the first group you
> > find containing the user (in case it is group A it is much more
> > convenient). Also, clients smart enough to understand nested groups, can
> > probably be smart enough to do some smart caching, and beating the
> > server a lot less often.
>
> Servers can also take advantage of the fact that group membership
> changes a lot less often than it is tested, and pre-calculate it when
> entries are added or changed. The server has full knowledge in most
> authentication/authorisation scenarios, so it can be *much* more
> efficient than a client when doing these tests.
Yep a control would be the right place to do a complex operation like
that, still does not warrant a different attribute imo.
> > > It looks as if the nested groups issue needs tackling. Should I expand
> > > this I-D to include it? The consensus seems to be:
> >
> > FWIW I think your original proposal is much simpler, and lets architects
> > decide what to do without artificial separations of members depending on
> > the fact they are groups or users.
>
> It is simpler and I would not want to complicate it without good
> reason, hence this discussion.
Yep, I was just posting my opinion in favor of simplicity.
> > Also it is more consistent, what if I have an Entry object listed as
> > emmebr in another that lately is added a groupOfEntries objectclass to?
> > Should the server go around all other groupOfEntries objects in search
> > for members to be changed to nestedGroupObject ?
>
> I am not sure that I understand your point there. Remember that
> groupOfEntries is a STRUCTURAL class, so it cannot be added to an
> existing entry or removed from one.
AHHH Right, that was the other thing in the back of my mind that kept
bogging me, but I forgot to post about it.
STRUCTURAL classes are often annoying and I think they should be used
only when the object is meant to be incompatible with other ones and/or
embed a unique new concept that should make it naturally incompatible
with other objectClasses.
What is the reasoning for it being STRUCTURAL here?
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer
email: idra@samba.org
http://samba.org
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
--------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext