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 21:45:09 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 got the proxy authentication working already. I even tested it when 
both proxy auth and http auth are required and it works.

There is just one small issue: I need the proxy host name to generate 
the kerberos service name (HTTP/proxyhost@REALM). The current 
NegotiateScheme code doesn't handle proxy auth at all and always uses 
the target host name which it retrieves from the Host header (is that 
the best way to get the target host?):

   if (isStripPort()) {
"") );
   } else {
     init( (request.getLastHeader("Host")).getValue());

I changed the NegotiateScheme to extend AuthSchemeBase (like 
NTLMScheme). Now I have access to the isProxy() method and can add the 
correct header (Proxy-Authorization or Authorization). However, to 
determine the hostname I currently have this:

   String host;
   if (isProxy()) {
     // FIXME this should actually be determined by the route planner?
     HttpHost proxy = ConnRouteParams.getDefaultProxy(request.getParams());
     host = proxy.getHostName();
   } else {
     host = request.getLastHeader("Host").getValue();
   if (isStripPort()) {
     host = host.replaceAll(":[0-9]+$", "");

I noticed a few frames up in DefaultRequestDirector.handleResponse the 
actual proxy host is known:

   if (this.proxyAuthHandler.isAuthenticationRequested(response, context)) {

     HttpHost proxy = route.getProxyHost();

     this.log.debug("Proxy requested authentication");
     Map<String, Header> challenges = 
this.proxyAuthHandler.getChallenges(response, context);
     try {
           this.proxyAuthState, this.proxyAuthHandler,
           response, context);
        } catch (AuthenticationException ex) {

But this information is not available to me at the FIXME location. I'm 
also ignoring any forced route now, but it seems wrong to copy paste the 
code from DefaultHttpRoutePlanner anyway, especially since that's just 
the default implementation anyhow and could be overridden.

Next thing I'll look into is why the redirect fails.


> 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