httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h
Date Tue, 06 Dec 2005 07:04:47 GMT
On Mon, Dec 05, 2005 at 02:17:09PM -0700, Brad Nicholes wrote:
> This was one of the question that I had when I added the AUTHZ_* status
> types.  I couldn't decide whether AUTHZ_DECLINED made sense or
> AUTHZ_DENIED.  To me AUTHZ_DENIED means no matter what, that we are done
> checking and authorization is denied.  While AUTH_DECLINED means that
> the provider checked and it can't authorize the user so continue down
> the list to see if something else can.  I'm looking at this in the case
> when we have multiple 'require' types listed:

The only question the provider should be able to answer is: "Do you think
this user is authorized to access resource foo?"

I believe what the implication of having multiple authz providers say "No"
is something outside of the provider framework.  (Somehow, satisfy may play
into this, too.)

> Ignoring SATISFY <whatever> for now, we still want each provider to be
> called in the listed order and whether authorization is GRANTED or
> DENIED may not be known until each one has been called.  Until then the
> status is simply DECLINED.  We can assume that DENIED and DECLINED mean
> the same thing as long as we get rid of the AuthzXXXAuthoritative
> directives.  If not then each authz module has to be able to communicate
> the difference between DECLINED and DENIED"

I do think we need to get rid of Authoritative, yes.

> BTW, I am starting to lean much closer to adding new mod_authn and
> mod_authz modules.  I just haven't been able to come up with a better
> home that makes sense for some of the directives.
> 
> mod_authn - general authentication directives
> authtype - for now until we decide to complete eliminated it
> authname
> 
> mod_authz - general authorization directives
> require 
> satisfy - looks like it would make sense here after moving it out of
> core.

I'd prefer slapping 'core' on their names than leaving an undecorated
'mod_authn' here.  Another alternative would be to just have them both in
'mod_auth_core'.

Even if it were split out, mod_authn_core really wouldn't perform too much
heavy lifting as the basic/digest mechanisms do the heavy lifting w.r.t.
authn providers.  But, for authz, because no one really 'owns' require or
satisfy, a mod_authz/mod_authz_core would do most of the provider
invocations - unless we can come up with a better module ownership of the
'core' authz directives.  -- justin

Mime
View raw message