Quanah Gibson-Mount wrote:
This would certainly work for me, and is I think, what I was trying to ask for originally, except I said the rootdn, when I should have said a proxy ID. ;) Then I could just add
access to suprivilegroup by dyngroupID compare
and be happy.
This already you have now in HEAD. I fear you'd rather need to add
access to suprivilegroup by dyngroupID __READ__
and be (un)happy...
Why would it need read? The acl's should be something like:
because dynlist uses an internal search, and an internal search need "search" on filter attrs and "read" on attributes to be returned. This before ITS#4806 enhancement.
access to group by uid=a read by uid=b compare
access to other group by uid=c read
etc
and then in dynlist, I supply a proxy ID that is used internally to do the comparisons to generate the membership. Then only that proxy ID needs to do any sort of internal lookups. The initial user's credentials are still used with the ACLs to see what, if anything, they can do with the generated information.
Something perhaps like:
overlay dynlist
dynlist-proxyID cn=dynlist
Then in my ACL's as well:
access to dn.subtree="cn=people,dc=stanford,dc=edu" attr=suprivilegegroup 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 groupAuthzTo).
p.