[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: proxy authorization acl
From:       Howard Chu <hyc () symas ! com>
Date:       2004-12-06 18:26:06
Message-ID: 41B4A43E.5000207 () symas ! com
[Download RAW message or body]

Kurt D. Zeilenga wrote:

> 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?
> 
> 
> 
I think that could work. Will have to think about this some more.

> 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


[prev in list] [next in list] [prev in thread] [next in thread]