httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: How to combine IP and user based AAA without Satisfy?
Date Fri, 18 Dec 2009 12:46:00 GMT
On 18.12.2009 00:36, Christian Seiler wrote:
> Hi,
> Since I'm also interested in AAA in future Apache versions, I decided to
> have a look at this.
>> In 2.4, *without* using the deprecated "Satisfy" via mod_access_compat,
>> you will always be prompted by basic auth, because the ip addresses are
>> only used during authz which comes after authn.
> This issue is found in ap_process_request_internal: If ap_satisfies(r)
> is not SATISFY_ANY (which it will only be with mod_access_compat since
> ap_satisfies else simply returns SATISFY_NOSPEC in 2.3+), it actually
> requires that an AuthN module (Basic, Digest, Form) actually
> authenticates a user.
> The current Apache implementation has is 3 different hooks that are run
> in that place:
>   1. access_checker
>        * Allow from / Deny from
>             (older versions, mod_access_compat)
>        * Some mod_ssl logic
>        * mod_lua (it actually provides access to every hook so there
>          isn't any real functionality behind it that the user doesn't
>          add him/herself)
>   2. check_user_id:   AuthN (mod_auth_basic _dist, _form)
>   3. auth_checker:    AuthZ (mod_authz_core ->  mod_authz_*)
> Previous logic (mod_access_compat, Apache up to 2.2) was:
>   * Satisfy All:
>         Check all 3 in the order access_checker, check_user_id,
>         auth_checker. If any fails, bail out.
>   * Satisfy Any:
>         Check access_checker. If that's ok, continue. If that fails,
>         run check_user_id and auth_checker and any of those fails, bail
>         out.

I agree with your analysis. Sorry that you had to do it again, I wanted 
to keep my inital post short.

> To me, all this seems to be violation of the separation between
> authorization and authentication and basically a leftover from before
> the AuthZ rewrite. What should happen (in my eyes) is the following:
>   1. Authentication phase: If it is possible to authenticate the user,
>      set r->user to the username. If not (no authentication data passed
>      with the request, user does not exist or even password wrong) the
>      r->user field is simply left with NULL. The authentication modules
>      by themselves do not send 401 or 403 headers if they fail.

Interesting idea.

>   2. Authorization phase: Only here it is determined whether the user
>      has to be authenticated (require valid-user for instance) or if
>      the user has to match any other criterion, such as source IP or
>      anything else. At that point, it would be nice to be able to somehow
>      detect if the condition that failed relied on a user (in that case
>      401 should be sent) or not (in that case it should be 403). Perhaps
>      a return code for authz modules.
> Also, access_checker seems to be a bit superfluous to me - since that's
> actually part of the AuthZ phase and was only added as an extra hook in
> the past in order to be able to have checks that don't actually require
> a user.

In trunk it is only used by mod_access_compat and mod_ssl. The mod_ssl 
use of the hook is non-trivial though.



View raw message