Re: icap in squid3

Good morning,

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.

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.

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.)

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.)

C.) The X-Header used to transfer the prefix if any.

D.) Something to force base64 Encoding on above headers

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.

How to actually do this I am not sure about. Will think about it a little
more and get back to you.

Have a good day and week.

Axel

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 Mon Feb 12 2007 - 00:57:05 MST