hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastiaan van Erk <sebs...@sebster.com>
Subject Re: Kerberos proxy authentication issue
Date Fri, 11 Dec 2009 22:48:04 GMT
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,
>> Sebastiaan
> Hi 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.


> Cheers
> Oleg
>> Oleg 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 testuser@SERVOY.COM from 
>>>> IPv4: for HTTP/tunneltest.servoy.com@SERVOY.COM
>>>> But for the proxy service you need a ticket to 
>>>> HTTP/tunnelproxy.servoy.com@SERVOY.COM.
>>>> 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,
>>>> Sebastiaan
>>> Sebastiaan
>>> I 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: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org

View raw message