Re: proxy authorization acl

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

I think we should work on both approaches; I guess I'm borrowing from 
one of Kurt's ideas, but I can't find the original posting. Currently, 
authz{To,From} is stored in the entries; it allows some flexibility, 
i.e. scoping, URLs for searches and groups, but yet it's an in-directory 
mech, with DSA-wide policy rules (e.g. the authz-policy and so).  What 
you suggest is an extra ACL permission, but this sounds a bit hijacking 
the ACL mech for something different.  Note that the authz{To,From} mech 
recalls ACIs, so we could generalize it further by using a sort of 
collective authz* attrs, so for instance, "ou=People,dc=example,dc=com" 
could allow proxyAuthx and "ou=Guests,dc=example,dc=com" could not.

What I'm thinkng about is a general apporach, which would also include 
the "limits" (with extensions), that does a

<feature>[.<styles>+<feature-specific-data>]
   <who>[.<styles>]
   <what>[.<scope>+<filter>+<what-specific-data>]

in <feature> we can place "access", "search limits", "controls" and 
more; "controls" could be split into "proxyAuthz", thus allowing 
"authzTo", "aauthzFom", "authzPolicy", and more, and "pagedResults", 
thus allowing "pageSize", "sizeLimit", "timeLimit" and more; in general, 
each control would allow to specify filters on the control's data (aybe 
by means f control-related hooks that work on the "controlType", 
"criticality" and extra data.

<who> would use all the ways we currently handle to define "by" in ACLs; 
<what> would be any whay to select entries, e.g. <DN>[.<scoping>], 
<filter>, <attrs>[.val=<value>] and so.  As such, the proxyAuthz control 
for a subtree for a set of persons could look like (e.g. hijacking the 
"limits" statement name):

limit
   control=proxyAuthz                                 # <feature>
   authzDN.children=o=Guests,dc=example,dc=com        # <what>
   dn.children=ou=People,dc=example,dc=com ssf=1      # <who>
   allow=to                                           # <action>

An access statement would be

limit
   access                                             # <feature>
   dn.children=o=Guests,dc=example,dc=com             # <what>
   dn.children=ou=People,dc=example,dc=com ssf=1      # <who>
   allow=write                                        # <action>

we have backward compatibility if:
"access" implies limits, and we add the harmless interpucntions "to" and 
"by";
the absence of "<feature>=<feature-name>" implies the old limits; or we 
can use a different statement name, and keep the old stuff around until 
transition is over.  I'd use a similar mechanism to allow the same stuff 
to be stored in the entries (and in "collective" attributes or simply in 
the subtree, like ACIs) to give more freedom (and allow distribution via 
replication) of these features (thru a well-thought draft?).

Ando.

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?
> > >   





   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497