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