Re: [ldapext] Nested group (was: groupOfEntries object class proposal)

[simo <idra@samba.org>]

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