Re: Multiple authentication domains?

Robert Collins wrote:

> We should probably simply use a new acl type auth_domain, and then allow
> tests against it in http_access, and some mechanism to place _requests_
> in an auth domain. We'll also need to add an auth domain parameter to
> the authentication config entries (ie
> (2.5 devel style)
> auth_param ntlm authdomainaclname1 program /foo/bar
> auth_param ntlm authdomainaclname2 program /foo/bar

Will probably be some kind of auth domain assignment, running prior to
http_access.

Another alternative is to tie proxy_auth ACL's to different domains, but
such a setup easily gets quite messy and may contratict itself as more than
one proxy_auth ACL may be used in http_access processing while the request
as such usually only can be in one authentication domain.

The way to extend auth_param is eaxly what I had in mind, but perhaps
switching place between scheme and domain...

> It needs to be requests because for digest && NTLM we don't know the
> username at the beginning of the auth process (vs basic where its always
> a single transaction).

Sure. As I said it should be based on "static" information such as
 * Source IP
 * Port where the request was accepted

> Most of the authentication data is already split out to make this
> straightfoward (and you could potentially implement only one scheme).

Thought so.

> However some things aren't as abstracted as needed. Some care will be
> needed...

Any pointer as to what more specific to look out for?

> For my sake I'd like to you to do this to the generic.modules branch :]
> (Several parts of the above will be easier - in particular the parser
> modifications will be quite a bit easier).

No opinion there.

> What's your desired timeframe?

It is an potential issue I see might become a real problem in more complex
setups. If I am to set a timeframe it is probably needed to be solved
within 6 months up to a year.. earlier if a real live cenario requiring it
appears and there is money in getting it solved ;-)

--
Henrik