httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <>
Subject SSLRequire, FakeBasicAuth and fall through.
Date Tue, 28 Dec 2004 19:38:06 GMT

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.

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

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

Is that worth the effort ? Any ideas ?


View raw message