Re: Extending the authentication helpers system?

I think the outline looks good but I have a couple of issues ....

I agree that each acl requiring either authentication (get teh username,
don't care _who_) or authorization (specific user names/groups) should have
a flexible list of auth types. However I think a safer, more flexible method
would be to alter the authenticate_program entry to be

authenticate_program auth_type pathandfilename any_needed_parameters

and then in the acl use
acl aclname proxy_auth auth_type username username ...
acl aclname proxy_auth_regex auth_type [-i] pattern ...
so to allow basic & ntlm you'd have (for example)

authenticate_program basic /usr/local/squid/bin/basicauth /etc/passwd
authenticate_program ntlm /usr/local/squid/bin/ntlmauth MY_DOMAIN
acl windowsusers proxy_auth ntlm REQUIRED
acl unixuser proxy_auth basic unixuser1 unixuser2
acl dstdomain .restricted.site.com unixusers windowsusers

would require authenicate of windows users via NTLM ot unixuser1 and
unixuser2 via Basic.

I think this is safer because it doesn't include userpasswds or
authentication secrets in the squid.conf file (a security issue as well as
raising all sorts of syncronisation issues) It will still allow for easy
filtering. We would need a separate table somewhere listing the order the
auth-types are to be presented in.

Now each authentication program can be protocol specific, and will only be
called for the correct authentication type. This means adding a new type
(such as digest) should require no further alterations to the core code. The
fallback process is just in the acl checking loop and (hopefully) we don't
have to block on the auth program?!? Also I think the browser is only meant
to present the authorisation type it is going to use (picked from the list
the proxy presents) (corrections please?) so the check simply becomes in
MatchAcl

...
CASE ACL_PROXY_AUTH
line= get proxy-auth line
array request=split(line, ' ')
  if (aclMatchAuthType(request,&ae->data))
      result = handle_external_auth (request[1],line)
  else
    /* wrong auth_type presented by browser - try next acl in list
        this may simply be an ok? */
     return FALLBACK_PROXY_AUTH;
switch (result)
  case AUTH_FINISHED_OK:
     /* user authenticated, now check for authorisation */
         authorised = handle_authorisation(user, aclstring)
    return authorised;
  case AUTH_IN_PROGRESS:
         /* we need more information from the browser - ie half way thru
ntlm*/
         return AUTH_IN_PROGRESS;
  case AUTH_FAILED:
       /* something went wrong, user cannot be authenticated. ie wrong
password, non-existnant user */
     return -1;
   case AUTH_RESTART_AUTH:
       /* a challenge response in NTLM might need the ability to reset the
auth process
           should never be needed except when a pc dies, OR someone is
cracking around */
     return -2;
  break;

and handle_external_auth simply finds a unused instance of the appropriate
auth_program from it's first parameter, and passes the whole line to it.
so we can build the external authorisation package in very easily - If we
can manage to not break squid-guard, that could do the authorisation aspect
in one big hit.

Ideally we can have a generically aware inner loop, with all the detailed
processing outside squid. We need that to be able to use improvements in
auth libraries for (say SAMBA/kerberos) easily.

Rob

----- Original Message -----
From: "Chemolli Francesco (USI)" <ChemolliF@GruppoCredit.it>
To: "'squid-dev'" <squid-dev@squid-cache.org>
Cc: "Chemolli Francesco (USI)" <ChemolliF@GruppoCredit.it>
Sent: Monday, July 17, 2000 11:46 PM
Subject: 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 - 17:08:37 MDT