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.
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
[EMAIL PROTECTED]:
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
Re: icap in squid3
Hi Alex,
Am 13.02.2007 6:03 Uhr schrieb Alex Rousskov unter
[EMAIL PROTECTED]:
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
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
[EMAIL PROTECTED]:
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
icap in squid3
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
Re: icap in squid3
On Fri, 2007-02-09 at 15:55 -0500, Jeremy Hall wrote: 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. I think you were on the right track with your patch[1,2]. If you can provide a separate %escape character for the username without the domain part, that would address Axel's needs, I think[2]. Perhaps your patch already does that -- I did not check. Thanks, Alex. [1] http://thread.gmane.org/gmane.comp.web.squid.devel/4091/ [2] http://thread.gmane.org/gmane.comp.web.squid.devel/4130 [3] http://article.gmane.org/gmane.comp.web.squid.devel/4068
