RE: [squid-users] 2 NCSA password files

From: David Parks <davidparks21_at_yahoo.com>
Date: Mon, 22 Nov 2010 22:42:58 +0700

I have a ballpark-similar requirement. What I did is write a custom authentication application and an ACL helper which work in tandem to authenticate and monitor user activity. Here's what it looks like (at least the parts that are relevant to your question):

I run 1 java based application which handles both user authentication (we integrate with a custom web-based application), and handles ACL requests.

The login doesn't need to be fast, but the ACL checks are called for each URL, so they need to respond immediately. Once a user authenticates we store the username in a hash table which is later accessed by the ACL helper quickly (and updated as needed by external events). In your case you could put the "fast" users into a bucket and have an ACL helpers that check that the user was added to the table (otherwise they can default to the slow group).

I found it easiest to write one application to do all of the above. The ACL helper and Authentication helper are implemented simply with a linux shell script that redirects standard in/out to and from a unix pipe, then in the java app I can simply read/write to the relevant pipe (just a file to java).

So the workflow looks like:
 1) User accesses a site through squid
 2) squid sends Digest authentication request
 3) User credentials are sent to the authentication helper
 4) Authentication helper script redirects to a named pipe
 5) Custom app reads the login info from the pipe, writes success/fail response to another named pipe, and caches the username as appropriate to identify the user as in the "fast" group or not
 6) Authentication helper script redirects above input back to user, user now is authenticated
 7) A custom ACL exists to match users to the fast group (or default them to the slow group)
 8) Squid calls the custom ACL helper for each URL request
 9) The custom ACL helper script redirects to another named pipe to be picked up by our Custom app
10) Custom app checks if the user is in the fast group and responds to the named pipe with a success/fail for the ACL match
11) The ACL helper script redirects the named pipe to STDOUT of the ACL helper
12) Squid matches the user to the fast group or defaults them to the slow group.

The "custom app" in this case could be as simple as calling the existing authentication helpers (twice if necessary to find the user in the fast or slow group). But it will need to handle caching the username as fast or slow so that the custom ACL requests can happen immediately.

If you go this route let me know and I'll post the shell scripts I use (and a few other pointers), unless you’re a shell script guru (I wasn't) it'll take a good few hours to figure out.

David

-----Original Message-----
From: J Webster [mailto:webster_jack_at_hotmail.com]
Sent: Sunday, November 21, 2010 4:43 PM
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] 2 NCSA password files

So, if my users change on a daily basis (sometimes hourly), can I update the acl file on the fly.
So, I'd have 1 ncsa file with the username and passwords for all users.
Then 2 acl files with high speed users and low speed users?

--------------------------------------------------
From: "David Parks" <davidparks21_at_yahoo.com>
Sent: Sunday, November 21, 2010 10:02 AM
To: "'J Webster'" <webster_jack_at_hotmail.com>; <squid-users_at_squid-cache.org>
Subject: RE: [squid-users] 2 NCSA password files

> If you write a custom ACL helper you can match users against any criteria
> you define, then implement the delay pools for users that matched your
> custom ACL helper.
 
Received on Mon Nov 22 2010 - 15:43:09 MST

This archive was generated by hypermail 2.2.0 : Mon Nov 22 2010 - 12:00:03 MST