[Date Prev][Date Next]
Re: ACL question
--On Wednesday, March 08, 2006 2:57 PM -0500 Matthew Comer
I have an interesting problem regarding delegated administration and the
use of LDAP to define security in applications. Specifically:
We currently have a DIT with several thousands of users. It is organized
in a structure which represents the structure of our business units. We
have offices which have ou's, departments within those, and so forth. We
have security officers within those units who can control the permissions
granted to their users, and we use ACL's to limit their scope of control
to only users within their office or unit. This structure is a little bit
rigid and hierarchical, but it works.
We define access to other applications (e.g. J2EE apps) via attributes
define on the people objects. So, if person A has access to app B they
will have an attribute defining their access to B. This is legacy and
predates my involvement, and is what we would like to change. We would
like to move to a group (groupOfNames) based approach which indicates
roles vs. the current fine-grained model.
HOWEVER - we're not sure how to enforce the following constraint: the
security officer should only be able to add and remove people to a group
IF THAT PERSON BELONGS TO THEM. The group objects sit elsewhere in the
tree and represent access to applications that span the organization.
I looked at enforcing this with sets in the ACL, but this requires know
both the group being modified ("this" in the ACL) and the person being
added. I don't believe that the latter is available.
Is this a problem that someone else has solved? Any pointers to a good
Have you looked at using dynamic groups? This would allow you to use your
existing attribute-based groups in a "member" form. Which means your
existing ACL rules for modification would work just fine, and all group
memberships are determined *dynamically*. No need to actually modify the
group entry itself, just the individual user objects.
Principal Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html