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

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

On Wed, Sep 19, 2007 at 10:07:00AM -0400, simo wrote:

> > > If nested groups are to be allowed, then I would rather see the
> > > nested groups listed in a separate attribute, e.g., called nestedGroups,
> > > so that implementations only need to read the entries that really
> > > are nested groups.
> > 
> > That would be a great improvement in efficiency. There would also need
> > to be an auxiliary object class to identify groups that might contain
> > such attributes - nestedGroupObject or perhaps groupOfGroups.
> > (Or the groupOfEntries class could permit the nestedGroup attribute as
> > well as the member attribute. I think I would prefer a separate
> > class.)
> 
> I really don't see any value in using a different attribute.
> An apple is always an apple even if you call it orange. If that
> attribute is present, the client has to do all the work anyway.
> The only difference is that you have to use a more complex filter to
> show the members of a group and probably also 2 indexes instead of just
> one.

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.

> > On Wed, Sep 19, 2007 at 09:48:14AM +1000, Luke Howard wrote:
> > 
> > > This is what Novell did with eDirectory (they also have an option where 
> > > nested members are presented as values of member).
> 
> Which is bad because at that point the client have no way to tell which
> group exactly a user is member of. It is good only for simple
> authorization schemes (and was probably done to keep old unix clients
> happy).

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.

> 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.

> 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.

> > 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.

> 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.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext