Extending the authentication helpers system?

Foreward: I am not on the list, so please Cc me any
discussions about this.

While working on the NTLM authentication, I kind of banged against
limitations in the current authentication/authorization system.
This had me wonder if and how it could be extended.

First issue: the authenticator.
As more authentication schemes get added (NTLM at least), the
squid <-> authenticator interface will prove to be too limited. For
instance, NTLM authentication will fall back to Basic, and since the
exchanged data are different, we need to have the authenticator know what
it's getting. Currently I'm using a kludge on the password field
(especially since NTLM authenticaion doesn't do authentication at all
right now, it just gets the user name and domain), but it is a kludge,
and I'd rather avoid it in the long term.

My idea is to change the authenticator protocol to:
<aclname> <authscheme> <authscheme-specific data>
This allows for easy filtering and fallbacks. An NTLM authenticator
module might thus look like (pseudocode):

line=readline
array request=split(line, ' ')
if (request[1]=="ntlm")
  ok=handle_ntlm_auth (request[2..])
else if (request[1]=="basic")
  ok=handle_basic_auth (request[2..])
if (ok)
  print "ok\n"
else
  print "err\n"

aclname should be the name of the ACL that triggered the authentication
request. It might be helpful when different resources require getting the
authentication from different sources. Might be a border-case, but since
we'd be extending the protocol anyways, I don't see the harm in taking
the chance and put it in.

So for instance a basic-authentication line could have the format
some_acl basic decoded_username decoded_password

while an ntlm-authentication could look something like
some_acl ntlm decoded_domain.decoded_username workstation_name lmchallenge
ntchallenge

This would basically require to rewrite all the authenticators around,
but the changes should be pretty trivial

Now for authorization:
It would be nice to have authorization helpers, the same way that we have
authentication helpers. The current authorization schemes should be left
in for performance reasons IMO, but some operations (i.e. NTLM-based
authorization) would be really heavy to support, potentially blocking and
only useful in border-cases.
My suggestion is to write some mechanism to have some kind of
authorizator interface. The authorizator could safely assume that the
user is already authenticated, in fact it shouldn't be passed the
received password at all. The basic workings of the protocol should be
similar to the extended authentication protocol I described above:
For instance, it could receive lines in the form
<aclname> <username> <requested_resource>
(the requested resource might be broken in its component parts, if deemed
useful) and return lines like "OK" or "DENY".

        ing. Francesco Chemolli
Received on Mon Jul 17 2000 - 07:50:11 MDT