Re: icap in squid3

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.

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.

> 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?

> 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?

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

> 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?

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 Mon Feb 12 2007 - 22:04:20 MST