httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject Re: svn commit: r354141 - /httpd/httpd/branches/authz-dev/modules/aaa/mod_auth.h
Date Mon, 05 Dec 2005 21:17:09 GMT
> {
>>>> On 12/5/2005 at 12:37:33 pm, in message
> <097D0C3CEAEFD0871B3E6EEA@st-augustin.local>,
>> Still need AUTHZ_DECLINED for now,  The converted mod_authz_user is
>> referencing it
>I think those references should be switched to AUTHZ_DENIED.
>AUTHZ_DECLINED has no purpose in a provider scheme, IMHO.  Declined is

>saying, "Um, doofus, you shouldn't have called me as I can't do
>with this."  With the explicit providers, we should be able to prevent

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:

require user foo1, foo2
require group foogroup
require ldap-user whoever
require owner

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"

>For the specific cases with mod_authz_user, since the invoker has the

>method_mask, it can do the check before invocation of the provider -
>we can abstract that away from the providers themselves.  I'd prefer
>providers not to even know about the method mask.  -- justin

Agreed, I think that method mask can easily be checked before calling
the provider so that the provider doesn't have to worry about it.  

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

mod_authz - general authorization directives
satisfy - looks like it would make sense here after moving it out of


View raw message