Re: Multiple authentication domains?

----- Original Message -----
From: "Henrik Nordstrom" <hno@marasystems.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Friday, April 27, 2001 1:13 AM
Subject: 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.

Also you would be making it overly complex for single sites.

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

With generic modules, the auth_param goes away - the same syntax used in
2.4 is available again - but still modularised :]. This gives more
flexability.

> > 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

Sure - I was think that something like
acl dom1 auth_domain
acl dom2 auth_domain

acl_domain_access allow dom1 myport80 !localclients
acl_domain_access deny dom1 all
acl_domain_access allow dom2 all

would be intuitive for existing squid users..

> > 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?

The user cache is a little fuzzy. More work could be done there. Also
the request flow is kinda ugly. I keep meaning to shuffle it into a more
sensible order.

> > 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 ;-)

Money helps :} I am likely do this out of interest within a year... but
I'm sure my employer would be willing to consider it as paid project.
(Which would mean I could code during the day - yay!). Anyway I'm happy
to throw peanuts as you code it, or whatever :].

Rob

> --
> Henrik
>
>
Received on Thu Apr 26 2001 - 16:16:15 MDT