Re: [ldapext] Dynamic group draft

[Pierangelo Masarati <ando@sys-net.it>]

Pete Rowley wrote:
> Howard Chu wrote:
>> http://www.ietf.org/internet-drafts/draft-haripriya-dynamicgroup-02.txt
>>
> 
> I am pretty concerned that introducing a new group type might simply
> further complicate the current LDAP group mess.  IMHO any addition to
> the LDAP grouping story should unify grouping mechanisms such that
> directly managed groups work the same way as dynamic groups from a
> non-administrative client perspective (which admittedly this draft does
> attempt), that nested groups be explicitly supported (because the
> management reality is that they are required), and that the server is
> tasked to do the work required for group membership so that the client
> is left with simple tasks to perform normal group operations such as
> enumeration and membership testing, and that those tasks are exactly the
> same no matter which type of group is being examined.  LDAP groups (both
> static and dynamic) are far too focused on the requirements for
> server-side access control and provide very little in the way of support
> to clients for use as a general purpose grouping mechanism - most
> notably because those two grouping methods work in completely different
> ways.  IOW "LDAP group" ideally should mean one thing to a client even
> if to a server it may be many sub-types. Necessarily, this would
> probably mean a "clean cut" from the current grouping mechanisms, and
> yes that makes this an unlikely event, but I actually think this is
> necessary if we are ever to get a coherent, usable, and scalable LDAP
> group story.
> 
> These were actually some of the requirements that fed into the
> FDS/Sun/Netscape roles feature, which I reference only as an example of
> an approach.  In that scheme clients performing non-administrative tasks
> have an exceptionally easy time working with roles, enumeration is a
> search, group membership tests are a compare, there is no distinction
> between role types at this level, everything is a DN, and yet managed,
> dynamic, nested, and TBD can all be supported by the client with a
> single group implementation - and all is subject to normal access
> controls for the DIT. The server OTOH is doing quite a bit of work to
> make this all happen, and that, IMHO, is how it should be.
> 
> Ultimately, I'd rather see nothing happen than another grouping scheme
> that adds to the client load without showing a reasonable path to
> grouping nirvana where current methods can be deprecated (or at least
> not considered for future client dev).


Well, for well-behaved clients I think this draft goes in the right
direction.  However, it depends whether you include the group manager
among the users or the administrators: for the group manager, complexity
will increase, while for other users it should remain exactly the same,
and the dynamic generation of part of the members should go unnoticed.

- existing static groups can be converted to dynamic by adding the
AUXILIARY class
- new groups can either be created as static plus the AUXILIARY class,
or dynamic groups.  Well-behaved clients allow filtering for the static
class since the dynamic one inherits from it
- adding/deleting members works as usual, treating them as static (a
notable exception is removing a dynamic member, which causes an error
and should actually lead to excluding the member)
- member exclusion before returning members and while comparing, and
things like that are dealt with by the implementation, so it's totally
transparent to the client (either normal user or administrator)

With respect to nested grouping, that's an interesting point.  I would
allow it for implementations that can guarantee that loops are
impossible.  I understand this would need to be somehow advertised so
that clients do not add dynamic group members to a dynamic group under
the assumption they will be expanded.

I don't think just dropping existing static groups and replacing them
with a new dynamic group would be an option, since there's too many
clients out there relying on groupOfNames and company; I don't thing
redefining it to allow dynamic groups would be an option either.

Cheers, 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