Re: NTLM + auth_rewrite

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>; "Chemolli Francesco (USI)" <ChemolliF@GruppoCredit.it>
Sent: Sunday, January 07, 2001 7:22 PM
Subject: Re: NTLM + auth_rewrite

> Robert Collins wrote:
>
> > ==== Other than the doco, auth_rewrite is ready to merge ====
>
> I have one large restructuring of the source layout that I'd like to
> discuss before the commit:
>
> * Conceptual change to call the helpers backend helpers and not modules

I'm happy to do that. I'll get on it after I commit the doco.

>
> * Group the schemes together
>
> auth_backends
> auth_backends/basic
> auth_backends/basic/NCSA
> auth_backends/basic/...
> auth_backends/ntlm
> auth_backends/ntlm/NTLMSSP
> auth_backends/ntlm/...
> auth_backends/...

I didn't want to stuff the CVS source tree around too much or I'd have done something similar already. What I was considering was
adding a helper sub dir under each scheme -
src/auth/basic/helper/NCSA
src/auth/basic/helper/...
src/auth/digest/helper/password
src/auth/digest/helper/...
src/auth/ntlm/helper/NTLMSSP
src/auth/ntlm/helper/...

>
> * Make sure that each installed "backend helper" has a unique name.

they do already - but do you mean in the configure script?

> Hmm.. thinking about it it might be a good idea to simply put all of
> them directly in auth_backends, without dividing on scheme. Especially
> if considering the idea below..

I disagree - see below.

> I also got the crazy idea of joining the auth helper protocols into one
> for all schemes using a more structured message format, and let the
> helpers register what schemes they support. Only schemes for where there
> exists a registered backend will then be announced, and if there exists
> multiple for one scheme then each is tried in order until a success. But
> this would be the next generation of auth_rewrite I think.

This has several issues:

* there is a lot of variation in the needed helper support for each scheme ie some schemes may not use helpers/ some like ntlm need
very complex helper support/ some need very little like basic & digest.

* the schemes already register when they are configured. multiple helpers & auth schemes will co-exist in what I believe are
fundamentally different fashions for each scheme - ie
* NTLM CANNOT use multiple helpers. EVER.
* Digest can, but only to retrieve the H(A1). It's easier and more efficient to build a mutli source helper that checks several
directories than to code squid into a loop through helpers.
* basic can use multiple helpers to perform authentication, but you will increase the time to deny significantly (you cannot tell
user does not exist from user password is wrong on most security protocols (by design).

* I cannot see any helper being able to support multiple schemes without being fairly complex internally - which raises the question
of why?

* and my key objection - from a architectural point of view, each scheme is independent now, sharing helpers will require
syncronisation across schemes which is the opposite of the direction I've taken squid.

* regarding the message format, it'd be easy enough to build one, but I can guarantee it'll simply announce the scheme-specific
extensions it supports. I.E. we're moving the complexity of different auth schemes into the helper communication protocol instead of
keeping it in squid.

I am happy to discuss it, I just don't see any benefits from it at this point. My personal opinion on the next generation of auth
changes is that
* backend provided group information (ie in the acl have group names, and then the helper tells us that john is in group
internet-users.
* upstream modular auth code - so squid can login into an upstream proxy using digest (or _shudder_ ntlm).
are important features.

Finally I do think that a semi-standard message format, so we can provide helper parsing code in authenicate.c would be a good idea.
Perhaps even a global format in a lib so helpers can be built using it too?
(some thing that defines how messages are sent/recieved, binary data encoded, and then lets the calling code actually handle the
meaning of the data transmitted.

Rob
Received on Sun Jan 07 2001 - 02:36:04 MST