Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <437A0837.6720.00AC.0@novell.com>
Date: Tue, 15 Nov 2005 16:11:27 -0700
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <justin@erenkrantz.com>,<dev@httpd.apache.org>
Subject: Re: Auth*Authoritative
References: <437A4634.1080809@slive.ca>
 <52DDE20E73517970297D2B4A@st-augustin.ics.uci.edu>  <437A4F4C.10301@slive.ca>
 <316FC790DB0064BDE27E6436@st-augustin.ics.uci.edu>
In-Reply-To: <316FC790DB0064BDE27E6436@st-augustin.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

  One other thing, the authorization type (valid-user, user, group,
etc.) should be unique among all of the authorization modules.  In other
words, only one authz module should be implementing valid-user not every
module like in the 2.0 architecture.  This is the main reason why you
now see the authz types like ldap-user, ldap-group, etc. implemented in
mod_authnz_ldap rather than user and group all over again.  There are a
couple of exceptions to this which are Group and File-Group implemented
in both mod_authz_dbm and mod_authz_groupfile.  I looked into trying to
fix this conflict only to find out that there is a reason for it and it
works in this case (although still confusing).  Keeping the naming
unique doesn't necessarily solve the ordering problem if you do
something like

require group foo
require ldap-group cn=foo-object,blah

But it does keep the authz modules from fighting over which one is
actually doing which type of authorization.

Brad

> {
> 
>>>> On 11/15/2005 at 3:32:25 pm, in message
> <316FC790DB0064BDE27E6436@st-augustin.ics.uci.edu>,
justin@erenkrantz.com 
> wrote:
> --On November 15, 2005 4:12:44 PM -0500 Joshua Slive
<joshua@slive.ca> 
wrote:

>> Getting closer, but I'm still confused.
>>
>> The Auth*Provider directives make sense to me for choosing which
>> mod_authn_* module will get a crack at doing authentication.  But
there
>> are two other ordering problems: mod_auth_basic versus
mod_auth_digest
>> and the mod_authz_* modules in the authorization phase.  It seems
that
>> these are where the Auth*Authoritative directives apply, and that
there
>> is no way (short of code editing) to do explicit ordering on these. 
Is
>> this correct?
>
>So, for mod_auth_basic and mod_auth_digest, they will usually be
exclusive 
>- this is indicated by the AuthType directive.  So, the conflict there
is 
>likely to be minimal.  Even if both were specified, the browser/client

>won't usually present *both* Basic and Digest authentications in the
same 
>request.
>
>However, if an authentication module doesn't use the provider system
(which 
>is allowed in order to permit source-compatibility with 2.0
authentication 
>modules), then then the Authoritative directives will control its 
>interaction with mod_auth_basic/mod_auth_digest.
>
>For Authoritzation, the problem is unchanged from previous versions of

>httpd.  You must rely upon Authoritative directives to properly order
the 
>authorization modules - until such time as someone goes and cleans
them up 
>too.  The ordering of mod_authz_* modules will usually be
non-deterministic 
>and subject to _HOOK_FIRST, _HOOK_MIDDLE, and _HOOK_LAST constants 
>determined at compile-time.  When a module is in the same 'priority'
class, 
>then the 'predeccessor'/'successor' logic kicks in at module 
>registration-time.  (This is why Nick wants to move some of our
bundled in 
>authorization modules to _HOOK_LAST.)
>
>Hope this clarifies some.  -- justin