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

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

On Wed, Sep 19, 2007 at 12:42:12PM -0400, simo wrote:

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

Server support would certainly be valuable in many cases and a control
sounds like a good way to ask for it. However, I think that is
orthogonal to the question of whether there should be two attributes.

Consider the case of a group giving access to some resource. As the
owner of the resource I have control of the group, so I can give user
X access to it by putting the DN of X's entry into the group as a
member. I might also control another group called Q whose members
should have access to the resource so I add that too. So far so good,
but if there is no distinction between leaf members and nested groups
*in the group entry itself* it would be possible for user X to give
access to my resource to other people by adding member attributes to
his own entry. As the resource owner I would not want that to be
possible. This alone seems like a good reason not to allow nesting via
the 'member' attribute.

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

I also avoid structural classes where possible. In this case it seems
reasonable though. A group is a fairly basic concept and if it did not
have a structural class of it own then group objects would have to be
based on something else. The closest I can think of is
organizationalUnit, but that is not really a good model for the common
uses of groups to control authorisation.

A further reason for it being structural is that groupOfNames is
structural. If groupOfEntries is to replace it then this should not
change.

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