Re: icap in squid3

Hi Alex,

Am 13.02.2007 6:03 Uhr schrieb "Alex Rousskov" unter
<rousskov@measurement-factory.com>:

> On Mon, 2007-02-12 at 08:38 +0100, Axel Westerhold wrote:
>
>> Well, the syntax you are proposing is somewhat limited.
>>
>> Here are my comments:
>>
>> 1.) cn=%u assumes that the used username equals the assigned CN which is
>> most of the time wrong. Normally the UID (or in AD the samaccountname) is
>> used for authentication. This will lead to a failure using cn=%u
>
>> 2.) The given URI is not flexible enough as it assumes that all user object
>> will always be located within the same root object. The used syntax provides
>> fast access because it will avoid search operations but will fail as soon as
>> the object is located in a sub OU or a totally different tree.
>
>> 3.) LDAP allows for all kinds of unicode chars we would need to encode
>> properly. While this is definately possible I wonder if there really should
>> be another encoding scheme impüplemented into squid.
>
> It seems to me that Jeremy is not proposing any syntax, encoding, or URI
> format (except perhaps for some default values). He wants to add ability
> to use any URI, with any LDAP (or not LDAP) tags. The patch gives user a
> set of supported substitutions. The user can use whatever substitution
> codes they need in whatever opaque text filling they need. Please see
> below for examples.
>
My point was that there is no use for a fixed LDAP template due to the way
LDAP is normally build. Let's move on to your proposal about substition and
encoding.
 
> We should be able to agree on that set without much trouble because
> adding more substitutions is not a problem. For example, if somebody
> needs a username without a domain, there should be a substitution for
> it.
>
> If there are more than 5-7 substitutions, we may want to argue whether
> single letter %S substitutions are better than easier-to-remember and
> harder-to-mistype ${LongNames}. I would probably vote for the latter,
> but it is not a big deal.
>
> Alternative encodings should be supported, of course, perhaps as
> $encodingName(string-to-be-encoded) substitution, where
> string-to-be-encoded may have variable substitutions? Again, there is an
> example below.
>

From what I can see there is following available info (if at all):

From Login:

Username
Prefix
Group

and that's it. Maybe my lack of fantasy let's me miss some of the additions.

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.

See my further comments below

>> What I think might work better is as follows:
>>
>> A.) A user authenticates using a proper DN authenticating against an LDAP
>> Server. In this case the username will be the DN and can be transmitted.
>>
>> B.) The user authenticates using a uid (samaccountname). Either this uid is
>> already usable on it's own an we can transfer it without any changes just
>> encoding it base64 if requested (which will keep us out of trouble with
>> UTF-8 or Unicode chars). In case we get this stuff from a windows user
>> sending us a domain prefix, we should be able to split the username into
>> domain and username. The hard part will be to find some kind of abstract how
>> to transfer this.
>
> Encoding aside, can the above two requirements be expressed as a set of
> substitutions?
>

They can but (see below)

>> What we definately need are the following configuration entries:
>>
>> 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.

>> B.) The X- Header used to transfer the username (bare username without any
>> instruction on how to use it (X-Authenticated-User, X-User, X-MyUser, X-Blah
>> etc.)
>
> Agreed. The icap_client_username_header option controls that now, but
> please see (C) below.
>
>> C.) The X-Header used to transfer the prefix if any.
>
> 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.

From what I can see we need to provide base64 encoding (normal X-Auth) and
URI encoding (LDAP) for now.

>> D.) Something to force base64 Encoding on above headers
>
> See for a suggestion above.
>
>> This ensures that the ICAP Client get's all the info we might have for the
>> user authenticating. This works fine if the ICAP Client will only deal with
>> one squid and it's auth scheme. As soon as we have x squids authenticating
>> to various sources but only one icap client we need to add some additional
>> information for the client to find the correct auth source. So we need to
>> tell the ICAP client the used auth (LDAP,WINNT etc) and where the target
>> (hostname:port) is. From there the client should use all infos received to
>> build it's internal request.
>
> Can substitutions handle this? Or do we need dynamic support for
> selecting an appropriate set of X-Headers, depending on how the user
> authenticated?
>

See above, but yes it definately will work like proposed above.

Have nice day,

Axel

> Cheers,
>
> Alex.
>
>
>> Am 09.02.2007 21:55 Uhr schrieb "Jeremy Hall" unter
>> <jehall@central.unicor.gov>:
>>
>>> Hello,
>>>
>>> I can't remember. What was the decided path for what was once the
>>> icap_auth_scheme? I recall there was some concern about my suggestion of
>>> having the ability to use ldap://hostname/cn=%u,dc=%d,dc=name,dc=int
>>>
>>> but I don't remember what the outcome was.
>>>
>>> _J
>
Received on Tue Feb 13 2007 - 00:17:07 MST