httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Seiler <chris...@gmx.net>
Subject Re: How to combine IP and user based AAA without Satisfy?
Date Thu, 17 Dec 2009 23:36:39 GMT
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.

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.

 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.

Just my 2c.

Regards,
Christian

Mime
View raw message