Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.2.0.14.2.20050101111431.04f2aeb0@pop3.rowe-clan.net>
Date: Sat, 01 Jan 2005 11:37:16 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: SSLRequire, FakeBasicAuth and fall through.
In-Reply-To: <Pine.OSX.4.58.0412282022550.3408@merlijn.local>
References: <Pine.OSX.4.58.0412282022550.3408@merlijn.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:38 PM 12/28/2004, Dirk-Willem van Gulik wrote:

>Thanks everyone for 2.0 - authentication is soo much easier to flexibly
>tie into complex setups where the auth is a 3d matrix of what, who and
>strenght. Having wizzed past things which used to be impossible - I am now
>hitting another level.
>
>Now there are quite a few modules which in one way or another rely on
>something filling out the c->user field as if Basic Auth was carried out.
>
>Just as an example (not picking on anything) take +FakeBasicAuth - as it
>is done now it essentially requires you to set an AuthType BasicAuth and
>also have a fake htpasswd file with a fluff secret.
>
>The reason for this is that these modules typically add an Authorization:
>header and then rely on modules deeper on the stack to decode these.
>
>And in the commercial world there are quite a few more which do exactly
>this same trick.
>
>This causes some problems; first of all - any fail will cause(unless you
>are clever) an auth header (basic-auth) which confuses upstream proxies
>and browsers (as they cannot auth as the auth comes from an kerberos
>token, some cookie, some sasl thing or a x509) and secondly it is hard to
>combine with a fall through, to a non basic auth, say, DigestAuth or some
>RSA Token if some higherup auth fails.
>
>I can think of two ways to clean this up a little:
>
>-       the addition of a mod_auth_basic_fake - which essentially
>        always decodes where it can - along with a clean up of
>        the assumptions that there is always a basic auth and that
>        it is always filled in that late.
>
>-       changing the social contract a bit - and actually allow the
>        setting of [c|r]->user relatively early in the chain by
>        any module. And a run through the exising code to follow
>        that assumption. This would break 3rd party modules and
>        cases with internal redirects; and in a way which is nasty
>        as it may get you a hole where you do not expect it. And
>        fixing that means a 'merge' sort of thing up the internal
>        subrequest chain across all modules.
>
>So I am wondering if this really is the right solution.

Agreed - even if we call this httpd 2.2, or httpd 3.0, will our
module authors truly audit the implications this has on their
modules, or will there be a flury of bugtraq activity about the
newly 'broken' modules (which reflects badly on httpd, although
in fact it's the module authors who have claimed their module
'runs' on httpd 2.2 who would have created the situation.)

One minor alternative would be to add the actual credentials
(e.g. fake auth headers at the request level for CGI, etc) to
the request immediately prior to running the request (after all
the request preprocessing is completed.)  Another minor tweak
would be to ensure this 'fake "BASIC" auth' was in fact just
a 'fake auth', and add a different token to Authorization so
it becomes much easier/safer to strip from the response.

>Would it not be better if we actually started adding a 'facts',
>'statements' or 'credentials' array to connection record.

I was thinking more of a linked list of credentials, with those
used to 'allow' the connection percolating to the head of this
credentials chain.  In a single transaction let's look at what
could occur (lets call the credentials chain 'CC' below);

  * Settings demand origin IP scope
    * Insert IP identity record into the CC
    * If transposed from .named.example.com notation, Link the
      DNS provider CC record used to authenticate this domain name.
  * SSL negotiation
  * Settings demand client certificate - we negotiate
    * Insert Client Certificate record into the CC
    * Link Certificate Authority/Store CC record, used to validate
      this Certificate, to the client cert CC rec
  * Client offered basic auth headers
    * Insert Basic auth record
    * Link to auth data store CC record(passwords file entry)

>Where anyone can add their stuff and where there is a clear social
>contract that you are allowed to change someone else their record ?

I don't believe you can change such records, they are not volatile.
What the developer MAY do is to insert another (higher priority)
record at the head of the auth chain.

This seems like a 3.0 sort of change, but I'm not sure folks think
we are ready for 3.0.  Then again, it could take quite a bit
of time to adopt such a change, so this might not be a problem.

Moving forward in httpd now, I'm coming to believe, is to look at
the real issues (what folks have offered hacks to accomplish) and
better address the issues so that developers don't trip over one
anothers' modules.  This can happen today with mod_rewrite, and
happen to today with FakeBasicAuth.  Creating API's which address
these real world needs will improve httpd, while lowering the odds 
of module interoperability issues.

Bill