Re: icap in squid3

On Tue, 2007-02-13 at 08:09 +0100, Axel Westerhold wrote:

> One comment on a nice feature I would like to have but still considering for
> security reasons:
>
> When an ICAP Server requieres auth for user mapping to rules/policies you
> sometimes run into a problem with sources with can't auth or destinations
> you do not want to require auth for. While you can use ACL's to get this
> done easily on squid sometimes the icap clients won't play ball. As a result
> some destinations are not using the icap virus scanner/ content system to
> make it work. So, maybe but just as a thought, it would be nice to use ACL's
> to automatically assign a username für those services so that they can be
> properly matched.

Will a default user name work? As a stop-gap measure, it is probably
much easier to implement than ACL-defined user name.

> >> A.) Do we need to split the username into parts and if so using which
> >> seperator. ('' = off or '\' or '+' etc.)
> >
> > Can the separator be up to the admin? Do we need to define it?
> >
>
> Must be configurable so empty string turns off and non-empty turns on and
> defines sperator. Samba for instance allows for Seperator modifications.
> Also, this gives squid some flexibility.

I was thinking that the user-configurable opaque text around individual
substitutions will define separators, if any. Is that too cumbersome?

> > Should we just support an arbitrary set of user-configurable header
> > names, with user-configurable values? If we add substitutions support,
> > then Squid should not really care about the meaning of the header. For
> > example,
> >
> > icap_client_add_header "X-Username" "$base64($UserName)"
> > icap_client_add_header "X-Prefix" "bar=$base64($Foo+$Bar)&foo=blah"
> > ...
>
> I like this from a technical point of view. But I can also see my customers
> which are most of the time used to windows gui and stuff and already
> complain about the squid conf, freaking out. Maybe, for common tasks we need
> some kind of macro producing the above code. At all, just as a thought, we
> might stay with a sfprint syntax first defining a format and then adding the
> values like
>
> icap_client_add_header "X-Username" "%s=%b",bar,$username
> Icap_cleint_add_header "X-Auth_Scheme"
> "LDAP://ldap.test.com:389/cn=%u,dc=%u,dc=test,dc=com",$username,$domain
>
> Where %s is a string without encoding while %b is base64 encoded and maybe
> $u is URI encoded etc. I know this asks for additional parsing but it might
> lessen the learning curve for many people.

I doubt GUI folks would freak out _more_ if we add shell-style
substitutions than if we add printf-style ones. GUI folks need a GUI
configuration tool that hides all this.

FWIW, I find shell-style more intuitive and less error-prone than
printf, but since I am not going to implement or pay for this, I would
not argue one way or the other. The developer should decide :-).

In either case, it would be great if the configuration code checked that
all substitutions are known/supported. In case of printf, it would be
nice to check that the %escapes match the arguments as well.

Thank you,

Alex.
Received on Tue Feb 13 2007 - 08:00:27 MST