Re: [squid-users] Squid and Single Sign On

Sorry for not beeing clear.

Henrik Nordstrom a écrit :

> On Tuesday 03 September 2002 15.18, Fathi Ben Nasr wrote:
>
> > > What is missing from your proposed approach is the "session"
> > > concept unless you are using some kind of authentication at
> > > Squid. What defines a "user", and how to connect this with "what
> > > login+password to use for this site"?
> >
> > What I meant is user a opens his browser, connects to a site,
> > browses this site and once hi tries to get in a protected area, his
> > is asked for credentials.
> > He continue to browse other intranet servers and each time he gets
> > in a protected area of one of these intranet sites, his
> > username/password are used to authenticate him to these areas/web
> > sites.
> > Squid could be configured to authenticate users and the
> > username/password the user gives for authenticating to squid are
> > used for autehticating to all intranet and only intranet/predefined
> > web sites.
>
> Yes, but this does not exacly answer my question, if put in the view
> of Squid.
>
> 1. What defines a "user"?

a pair of username/password that are the same for the apache server: I
mean apache and squid use different mudules to authenticate users against
two different datasources but the two auth datasources contain the same
username/password pairs in different enctypted formats.

>
>
> 2. How to determine if the login+password may be sent to another site?

This is what I ma looking for.
Is there a directive that tells squid to pass the credentials used by the
user to authenticate to squid to some prelisted web servers and not to do
so and request user to give his credentials for others.
And in case squid does not use authetication (squid as http_accel for
public and non public areas in an intranet), use the first credentials
supplied by a user to autheticate against a protected area for other
protected areas on the same domain/ip/web server.
A similar approach, but using cookies, is done but an anonymizer cgiproxy
(http://www.jmarshall.com/tools/cgiproxy/).

>
>
> The best answer to '1' is "an authenticated user", by authentication
> running at the Squid level.
>
> And the answer to '2' is by Squid configuration.
>
> As idicated before much of this is very much doable if using Squid as
> a reverse proxy infront of "your" servers. You then have pretty much
> full control over what to do.
>
> Doing the same in a "forward proxy" is not something I would
> recommend. For "forward proxying" the redirector approach is
> recommended, with a catalog of preconfigured login+password to use
> for the different sites. An application of this is for example if all
> your employees should have access to a password protected site on the
> Internet but you do not want to distribute the login+password to
> all..
>
> > > If using Squid as an accelerator infront of your servers then a
> > > number of other possibilities are available and quite nice things
> > > can be done. See for example our eMARA product line.
> >
> > What is eMARA ?
>
> The reverse proxy product line from MARA Systems AB. Uses Squid as the
> proxy engine. See http://www.marasystems.com/products/ for further
> information or contact me privately.
>
> Regards
> Henrik

(See attached file: smime.p7s)