Robert Collins wrote:
> 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 ...
Looks good. Or actually I would use
authenticate_program nametag type program arguments...
acl aclname proxy_auth nametag username ...
To allow two different NCSA auth classes for example, replacing the
auth_class tag.
> 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)
??? Why would anyone do that in the first place?
> 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.
Could be in the order the corresponding authenticate_programs's are
specified.
> 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.
It would be good if a way to cache the authentication could be found
also. Having a roundtrip to a external process (or even worse, remote
server) on each and every request is quite expensive.
> The fallback process is just in the acl checking loop and (hopefully) we don't
> have to block on the auth program?!?
You don't. The ACL loop already takes care of that, suspending the
request while the authenticate_program helper is doing it's work.
> 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
Exacly. The server gives the alternatives, and the client picks the one
it feels most suitable.
/Henrik
Received on Mon Jul 31 2000 - 17:14:33 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:33 MST