Re: slapo-dynlist desgin question(s)

[Pierangelo Masarati <ando@sys-net.it>]

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.