Re: Dynamic Groups

[Peter Marschall <peter@adpm.de>]

Hi,

On Thursday 29 May 2003 19:13, Howard Chu wrote:
> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Tod Thomas
> >
> > Well, I haven't read through Jeff's reference in its entirety so the
> > answer may
> > be contained therein.  What I got from google before I posted this
> > request is
> > that you essentially use attributes to define the various 'groupings'
> > and then
> > use a search filter contained in an LDAP URL to find all entries that
> > have that
> > attribute thereby deriving the contents of the 'group'.   Since the
> > attribute
> > is local to the individual entry, and potentially it was valued and is
> > maintained by an automated process, the addition or removal of that
> > entry's
> > 'group' attribute seems to provide its dynamic status.
>
> This definition would imply that Dynamic Groups are a concept that only
> clients care about, since presumably a client must issue a search on the
> LDAP URL that defines the group. Since it is an ordinary search request,
> then I would suppose that any LDAP server will support this.

No, dynamic groups are purely server-sided. To the client they appear as a 
regular groupOfNames or groupOfUniqueNames with member or uniqueMember
attributes.
The member attributes are the DNs of a search filter executed when a client
asks for the members of this group. This way dynmic groups enforce consistency
be eliminating the need for duplicate infomation.

I.e. on the server side it may look like

dn: cn=finance,ou=groups,o=company
objectclass: dynamicGroupOfNames
cn: finance
searchUri: ldap:///dc=foo,dc=org??sub?(ou=finance)

to the client it looks like

dn: cn=finance,ou=groups,o=company
objectclass: groupOfNames
cn: finance
member: cn= joe beancounter,ou=people,o=company
member: cn=jane beancountress,ou=people,o=company

When Joe B. leaves the finace department, to clients the group's members
will change without touching the group's definition.

With classic groupOfNames you need to administer people and groups
with dynamic groups changes in the people's objects are replected 
automatically.

The major disadvantage is that dynamic groups may be slow because the
server has to do a ldapsearch whenever a client asks for the members.
This is a problem that even commercial vendors admit.

> > If so is the concept a standard, a proposed standard, or a
> > proprietary idea implemented by a few vendors?

AFAIK it is an idea implemented by at least one vendor I know.
I consider it a very interesting idea.

> > Won't LDAP eventually run into
> > a hard limitation, or a performance limitation, using attribute based
> > 'dynamic
> > groups' as I described above due to the large number of
> > attributes that
> > could
> > potentially end up in a single entry?

IMHO creating attributes in entries just for dynamic groups is a 
misunderstanding of the concept. 
Creating static groups is be easier & faster in this case. (why enforce
a server side search? ).
But creating dynamic groups for attributes already existing (and 
necessary) in the "member" objects might really save work and
increase consistency.

> > The direction I'm heading in here is the
> > possibility of using dynamic groups as a form of role based access
> > control.

This sounds like you ask for an extension of the syntax of the 'access' 
statement in slapd.conf
  access to <what> [ by <who> <access> [ <control> ] ]+
so that the <who> clause can also be something like
  filter="ldap:///dc=foo,dc=org??sub?(memberOf=role1)"

To me this is different from general dynamic groups.

But it would require a search operation for each evaluation of the affected 
ACLs. This does not look like it will be very fast ;-)

Peter
-- 
Peter Marschall
eMail: peter@adpm.de