access *to* a group?

[Colin Higgs <colin.higgs@ed.ac.uk>]

Right, having read the FAQs for openldap, the archives of
openldap-software, and one or two papers floating around the 'net on
LDAP groups, I think (and hope) I understand the concept of groups in
LDAP in general and openldap in particular. One thing I'm still having
trouble with is access control *to* a group (not *by* a group - this is
covered in http://www.openldap.org/faq/data/cache/52.html).

What I'd like to do is to organise my LDAP objects into groups somehow.
There should then be at least one admin object (possibly also a group)
for each group. A simple example would be "adminA" has write access to
members of groupA, "adminB" has write access to members of groupB and
"admin" has write access to members of groupA and groupB.

I can think of, or know of, 4 ways to implement groups in LDAP:

1) Pretend branches of the LDAP tree are groups. This makes access
control very easy, but doesn't seem very flexible: what if someone is to
be in more than one group, for example?

2) Create a list of dns in the member attribute of a groupOfNames or
groupOfUniqueNames object. This is the way I was thinking of
implementing groups. This makes it easy for client programs to find
members of any given group and seems to collect them together nicely.
Unfortunately, while it is certainly possible allow for access to
something *by* a groupOfNames, I can't see any obvious way of
restricting access *to* a groupOfNames.

I'm assuming here that something like:

access to filter="dn=myGroupDN,member=*" by groupAdmin write

(where "dn=myGroupDN" stands in for and LDAP filter on the dn of the
group in question) will not work, since this will just return the dn of
an object matching the dn of myGroup whose member attribute exists (in
other words just the dn of the group - not of the members).

3) Every object which could be in a group has an attribute
"memberOfGroups" which holds the names of all the groups to which this
object belongs. I can think of controlling access to this with something
like:

access to filter="memberOfGroups=myGroup" by groupAdmin write

but I have a couple of issues with this. Firstly - surely there will be
a performance hit if access control is based on a search. Secondly - it
just seems to me that a single object that holds the group members (and
thus somehow represents the group) is just neater.

4) Use "dynamic groups" as dreamed up by Netscape and discussed in
http://www.webtechniques.com/archives/2000/05/wilcox/. This seems sort
of like (3) except that group membership is based upon other, non group
specific, attributes. The way this is done is by representing the group
as a search (which is encoded as an ldap URL). This sounds nice and, as
the author of the referenced article suggests, can cope many more group
members than other techniques. Unfortunately, I think I would be
travelling a bit too far off the openldap track as far as access control
is concerned.

So, does anyone know better? Can I have access control to a groupOfNames
as in (2)? Is that a silly way to do it? Is anyone else restricting
access *to* groups? Can Flash Gordon really escape the Cliffs of Doom
and save the Earth?

Colin.

-- 
Colin Higgs,
Chemical Engineering
University of Edinburgh                 Email:  colin.higgs@ed.ac.uk
King's Buildings, Mayfield Road,        Tel:    +44 (0)131 6508557
Edinburgh, Scotland, EH9 3JL            Fax:    +44 (0)131 6506551