[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapo-dynlist desgin question(s)

--On Monday, January 22, 2007 10:22 PM +0100 Pierangelo Masarati <ando@sys-net.it> wrote:

Quanah Gibson-Mount wrote:

--On Saturday, January 20, 2007 4:09 PM +0100 Pierangelo Masarati
<ando@sys-net.it> wrote:
access to dn.subtree="cn=people,dc=stanford,dc=edu"
    by dn.base="cn=dynlist" compare

After ITS#4806 enhancement, "compare" would be enough, if the proxy ID
is implemented.  At this point, the proxy ID could be contained in the
entry itself, to allow more granular, data driven identity selection.  A
mechanism like authzFrom could be used to select who's authorized to
assume the proxy ID and thus to get to override access rule to the
hidden data.  Something like:

    <dynamic group>: <static members>, (<dynamic members> + <authzFrom>)

when reading <dynamic group>, static members undergo usual ACLs; dynamic
members undergo usual ACLs for their direct access; plus, if the
client's identity complies with the <authzFrom> rule, the <dynamic
group> identity is assumed to perform dynamic group expansion, otherwise
the client's identity is used.

To simplify things, we could well recycle authzFrom to check if the
client is authorized to use the dynamic group's identity, and, in case,
let the client assume the privileged identity by using the dynamic
group's DN.

Or, we could define /configurable) dynamic group specific attrs that
implement the dynamic group's identity (groupManager?) and authorization
rules (groupAuthzFrom?; groupAuthzTo would make sense as well; it could
be used to check if a dynamic group is allowed to let a user assume the
privileged identity when accessing a certain datum, the "to" of

I guess my issue here, is that I want the proxy ID to not be associated
with the client's ID at all.  I simply want a way to have the dynamic
group to use the ACL's to decide whether or not the client has read or
compare to the membership list, and if it does, then to use an internal
identity that knows nothing about the client itself to do the compare or
membership generation as necessary.  So I guess the second solution
would work best in that case?

Well, mine was basically a suggestion to make things more finely tunable; of course, a safe default would be, for example, if no dynamic group exploitation authorization were defined, to allow users to use the dynlist and to deny anonymous. The latter could be enabled by setting groupAuthzFrom to "*" (shortcut for "dn.regex:.*").

So, in the end you would have what you need, while the feature could be
restricted as needed.

Sounds great to me. Of course, in my case, since my ACL's deny access to anonymous to the group entry, they wouldn't see it anyhow. ;) Although I probably will have some groups that are world readable, which is part of why I'd want an internal identity with the right authority to lookup against the attribute rather than anon.


-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html