Oleg Kalnichevski wrote:
Sebastiaan van Erk wrote:Hi Oleg,Thanks for your reply. There's a good chance I'm going to have to get this working, even if it means I'm going to have to delve into this myself. I'll contact the original developer and see if he sees anything obvious, but in any case,if I succeed in getting it working, I will happily contribute the patches.Best regards, SebastiaanHi Sebastiaan Cool. In my turn I will happily help with HttpClient specific stuff.
Hi Oleg,I also found the reason why the redirect doesn't work. Basically it comes down to the following:
The Kerberos auth can have a sequence of challenge/responses, that keep resulting in 401 until the authentication succeeds. After each challenge, the authenticate method in the same NegotiateScheme instance is called, and it processes this new information. So far so good.
But when the request gets redirected to a new URL it basically means the auth succeeded, and the NegotiateScheme instance is in "ESTABLISHED" state for the OLD request.
Now the new request also gets a 401, and authenticate is called again, however, it is called in the OLD instance, for the OLD request. Basically a *new* instance from the scheme factory is necessary for the new request.
I can think of two fixes:1) if http client detects a redirect, it also throws out the old AuthScheme and uses the auth scheme factory to generate a new one 2) the NegotiateScheme instance detects that the URL has changed by inspecting the request, and resets its internal state.
I like solution number 1 better, but I'm not sure of what the consequences might be for the other auth schemes. It seems to me that it is the right approach though, no matter what the scheme; if you follow a redirect, just create a new instance.
The only thing I have to debug now is why the tickets are requested from the KDC even though they're already in the ticket cache. This will cause a huge latency (a round trip to the KDC for every HTTP request). Once that is fixed I believe all problems are tackled.
I kept it for last though because I think it's the most difficult to debug. :)
Another thing I want to look into is if the auth header is reusable for a specific period of time, so that you can do preemptive auth instead of a challenge response cycle every time. Not sure if it's possible though, because that would seen to be open to a replay attack. On the other hand, one can generate the first token of the negotiation preemptively I think, assuming the first challenge from the server is empty.
Regards, Sebastiaan
Cheers OlegOleg Kalnichevski wrote:Sebastiaan van Erk wrote:Hi,I'm not sure it's supported yet in httpclient-4.1-alpha1, but continuing on my kerberos quest, I was trying the next phase: kerberos proxy authentication.This time I'm requesting a public url from the target server via a kerberos protected squid proxy. Again I tested this with firefox, and it works fine. (The final phase, kerberos proxy AND kerberos server, also works with firefox).However, when I add the following two lines to the Kerberos http client example:HttpHost proxy = new HttpHost("tunnelproxy.servoy.com", 3128);httpclient.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, proxy);The proxy authentication fails. It tries to authenticate to the service for the target web server instead of for the proxy service, that is, I get the following entry in my kdc.log:2009-12-11T14:22:12 TGS-REQ [email protected] from IPv4:85.147.225.232 for HTTP/[email protected]But for the proxy service you need a ticket to HTTP/[email protected].Is this a setup issue on my side, or is Kerberos proxy auth not yet supported, or is this a bug?Again I included the wirelog for further details. Best regards, SebastiaanSebastiaanI have some bad news for you. I suspect none of the actual HttpClient committers might be able to help you with Kerberos related problems. I, for one, have neither time nor inclination to dive into the subject. Kerberos code is fully based on user contributions. You may want to get in touch directly with the contributor of SPNEGO auth scheme [1] and _very politely_ ask him for help. I will happily review and commit patches, but my personal involvement will stop there.Oleg [1] http://issues.apache.org/jira/browse/HTTPCLIENT-523 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
