[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: proxy authorization acl
I rather the processing of an operation be subject to the rights
of various stable factors (in the life of the operation), the
authorization identity being one of those factors. However,
one could have a factor "is assumed identity?" (or the
inverse):
access *
by self !assumed write
by self read
Would this give you the needed control over access?
Kurt
At 08:08 PM 12/4/2004, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>
>>We already have a proxy authorization policy mechanism
>>in authz-regexp (sasl-regex), why do we need another?
>>
>Well... the current policy mechanism says user A can authorize as user B. This proposed mechanism allows limiting this so you can say "user A can authorize as user B but only within this defined scope." The particular need here is with an administrative tool which binds as a proxy user and is used to manage one particular subtree. In that subtree it needs to operate with rights of the real user. But it should not have any of that real user's privileges in any other part of the directory.
>
>>Kurt
>>
>>At 05:59 PM 12/4/2004, Howard Chu wrote:
>>
>>
>>>OK, it seems we need something like this:
>>>access to dn.subtree="ou=groups,o=foo"
>>> by dn.base="cn=groupProxy" proxy
>>>
>>>which basically says that only the "cn=groupProxy" identity is allowed to use proxyAuthorization privileges on the target. In the absence of the proxy right, proxyAuthorization is ineffective. I think it's a bit problematic because anyone who has been using proxyAuthorization previously would now have to add "proxy" rights to all of their existing ACLs. But conceptually it matches the behavior of the other ACL rights (i.e., default denied, must be explicitly granted). Comments?
>>>
>
>
>--
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support