You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Sebastiaan van Erk <se...@sebster.com> on 2009/12/11 14:36:30 UTC
Kerberos proxy authentication issue
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:85.147.225.232
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
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2009-12-30 at 14:00 +0100, Sebastiaan van Erk wrote:
...
> Hi Oleg,
>
> I'm still working on this, just been on a bit of a break during
> Christmas, just so you know.
>
> I have a question on the effects of the following method:
>
> /**
> * Tests if the authentication scheme is provides authorization on
> a per
> * connection basis instead of usual per request basis
> *
> * @return <tt>true</tt> if the scheme is connection based,
> <tt>false</tt>
> * if the scheme is request based.
> */
> boolean isConnectionBased();
>
> According to the currently submitted implementation, the negotiate
> scheme is connection based and returns true here. However, in my tests
> with apache + mod_auth_krb, it seems that mod_auth_krb does request
> based authorization. My Squid proxy seems to do connection based auth.
>
> The problem I have is that if I want to do preemptive auth then I don't
> know how to do it on a request basis if isConnectionBased() returns
> true, because http client doesn't try to authenticate the second request
> on a connection in this case (understandably).
>
> Theoretically returning false only hurts performance, and will allow
> preemptive auth for mod_auth_krb to work.
>
> Returning true breaks non-restartable-requests (streamed post entities
> for example), because even if you authenticate the connection with a
> HEAD request or something like that, no preemptive auth is done on the
> streaming request.
>
> Maybe I'm just implementing preemptive auth wrong... What I do is add
> the following interceptors to the http client instance:
>
> private static class PreemptiveAuth implements HttpRequestInterceptor {
>
> public void process(final HttpRequest request, final HttpContext
> context) throws org.apache.http.HttpException, IOException {
> final AuthState httpAuthState = (AuthState)
> context.getAttribute(ClientContext.TARGET_AUTH_STATE);
> if (httpAuthState.getAuthScheme() == null) {
> final AuthScheme authScheme = (AuthScheme)
> context.getAttribute("http-preemptive-auth");
> final CredentialsProvider credsProvider = (CredentialsProvider)
> context.getAttribute(ClientContext.CREDS_PROVIDER);
> final HttpHost targetHost = (HttpHost)
> context.getAttribute(ExecutionContext.HTTP_TARGET_HOST);
> if (authScheme != null) {
> final Credentials creds = credsProvider.getCredentials(new
> AuthScope(targetHost.getHostName(), targetHost.getPort()));
> if (creds != null) {
> httpAuthState.setAuthScheme(authScheme);
> httpAuthState.setCredentials(creds);
> }
> }
> }
> }
> }
>
>
> private static class PersistentAuth implements HttpResponseInterceptor {
>
> public void process(final HttpResponse response, final HttpContext
> context) throws org.apache.http.HttpException, IOException {
> final AuthState httpAuthState = (AuthState)
> context.getAttribute(ClientContext.TARGET_AUTH_STATE);
> if (httpAuthState != null) {
> final AuthScheme authScheme = httpAuthState.getAuthScheme();
> context.setAttribute("http-preemptive-auth", authScheme);
> }
> }
> }
>
> So my questions basically are:
>
> 1) What to do about the fact that not all implementations seem to be
> connection based?
Simply make this configurable either through a constructor parameter or
based on the execution context.
> 2) Is there a way to send preemptive auth per request even if the scheme
> says it's connection based?
I do not think so.
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
Oleg Kalnichevski wrote:
> Sebastiaan van Erk wrote:
>> Hi Oleg,
>>
>> Oleg Kalnichevski wrote:
>>> Sebastiaan van Erk wrote:
>>>
>>>> Hi Oleg,
>>>>
>>>> Thanks for adding this. I'm currently a bit stuck on the caching of
>>>> the tickets, which really needs to be fixed, but it looks like I'll
>>>> have to dive into protocols/APIs deeply (JAAS, Java GSSAPI, SPNEGO)
>>>> to figure it out.
>>>>
>>>> There is however one thing about the SPENGO authentication protocol
>>>> that does not yet fit nicely into the httpclient API, namely, if you
>>>> look at the diagram:
>>>>
>>>> http://issues.apache.org/jira/secure/attachment/12419383/SPNEGO_cropped.png
>>>>
>>>>
>>>> What you see is a series of requests back and forth, with the last
>>>> response containing the final negotiation token NOT having a
>>>> response code of 401. In the diagram it's a 200, but in my case
>>>> (with the redirect), it was a 3xx. In any case, the token should go
>>>> back into the authentication scheme.
>>>>
>>>
>>> This is somewhat similar to NTLM authentication, where the final
>>> response code may also be 3xx, so HttpClient should be able to
>>> handler such situations, worst case with some API extensions.
>>>
>>>
>>>> BTW, I quickly hacked a response inteceptor which would do this for
>>>> me (it was a hack, because it just called authenticate() again with
>>>> the token and a null HttpRequest (since you don't have a request in
>>>> the response interceptor) and at least GSSAPI was able to complete
>>>> the negotiation. I did this because I was hoping this would solve
>>>> the ticket caching problem, i.e, hoping that the tickets would be
>>>> "committed" if the negotiation completed, but unfortunately this was
>>>> not the case.
>>>>
>>>> I don't really know the authentication API should look to support
>>>> this protocol... and it might in the end not really be necessary,
>>>> except perhaps for mutual authentication.
>>>>
>>>> I'm going to look into the SPNEGO/GSSAPI stuff now to fix the
>>>> caching, so I'm still on this. I just wanted to keep you posted.
>>>>
>>>> Regards,
>>>> Sebastiaan
>>>
>>> Keep us posted on the progress.
>>
>> I working code including caching, but there is still a bunch of
>> smaller issues which are still up in the air. I can post the code I've
>> got so far, should I make a new JIRA issue for this, or add it to 523?
>>
>> The current status is:
>>
>> - Both http auth and proxy auth work.
>>
>> - The mutual auth works now, with a response interceptor specific for
>> the Negotiate scheme. Perhaps this could somehow be integrated into an
>> API change (in NegotiateScheme I added a
>> "completeAuthentication(HttpContext) method which is called from the
>> response interceptor after it calls processToken with the final token).
>>
>> - I can get the caching to work now, turns out this is weirdness in
>> the JDK kerberos implementation. You can do 1 of 2 things:
>> a) set useSubjectCredentialsOnly to false. In this case the ticket
>> cache of the OS can be used to get the TGT, but service tickets are
>> not read from here and NOTHING is cached. Terrible performance, but no
>> double login required (if a TGT is already present, you don't have to
>> type your password).
>> b) set useSubjectCredentialsOnly to true. In this case you must
>> sign on yourself with JAAS and a LoginContext and explicitly execute
>> the http client methods in a Subject.doAsPriveleged block, which is
>> annoying. You have to provide credentials since Java won't look in the
>> ticket cache, so you need to enter the credentials to get a TGT.
>> Fortunately it DOES cache credentials with the Subject. Since it's
>> single sign on (once in the application combined with
>> Subject.doAsPrivileged calls), the credentials used by the AuthScheme
>> are dummy credentials (by that time, you're already logged in).
>> I can't do anything about any of this, it's the way the Java Kerberos
>> implementation works, so the only thing I can think of is adding an
>> example using JAAS and Subject.doAsPrivileged and explain the
>> benefits/problems with each approach in the example comments.
>>
>> - I haven't looked into the preemptive stuff yet.
>>
>> - The negotatiate scheme is connection based according to the docs I
>> can find online, but my mod_auth_krb in apache doesn't seem to agree,
>> so with each request I get another 401 and another negotiate cycle.
>> HttpClient correctly does not try to reauthenticate, so I think this
>> is the module's fault. Anyway, http client does reauthenticate after
>> the 401, so it works.
>>
>> Regards,
>> Sebastiaan
>>
>
> Hi Sebastiaan
>
> I am glad you have been making progress with fixing SPNEGO issues. I
> would like to suggest the following way forward. Submit your changes in
> a series of relatively small, incremental patches. Start with more
> important issues first. I'll be reviewing those patches and trying to
> find ways to adapt the existing API to the peculiarities of Kerberos
> authentication. Please also consider investing some time into
> contributing additional content for the Kerberos related sections of the
> HttpClient tutorial, especially to help deal with JDK implementation
> weirdness and explain various trade-offs. Feel free to re-use the same
> JIRA ticket or open new ones as you see fit.
>
> Cheers
>
> Oleg
Hi Oleg,
I'm still working on this, just been on a bit of a break during
Christmas, just so you know.
I have a question on the effects of the following method:
/**
* Tests if the authentication scheme is provides authorization on
a per
* connection basis instead of usual per request basis
*
* @return <tt>true</tt> if the scheme is connection based,
<tt>false</tt>
* if the scheme is request based.
*/
boolean isConnectionBased();
According to the currently submitted implementation, the negotiate
scheme is connection based and returns true here. However, in my tests
with apache + mod_auth_krb, it seems that mod_auth_krb does request
based authorization. My Squid proxy seems to do connection based auth.
The problem I have is that if I want to do preemptive auth then I don't
know how to do it on a request basis if isConnectionBased() returns
true, because http client doesn't try to authenticate the second request
on a connection in this case (understandably).
Theoretically returning false only hurts performance, and will allow
preemptive auth for mod_auth_krb to work.
Returning true breaks non-restartable-requests (streamed post entities
for example), because even if you authenticate the connection with a
HEAD request or something like that, no preemptive auth is done on the
streaming request.
Maybe I'm just implementing preemptive auth wrong... What I do is add
the following interceptors to the http client instance:
private static class PreemptiveAuth implements HttpRequestInterceptor {
public void process(final HttpRequest request, final HttpContext
context) throws org.apache.http.HttpException, IOException {
final AuthState httpAuthState = (AuthState)
context.getAttribute(ClientContext.TARGET_AUTH_STATE);
if (httpAuthState.getAuthScheme() == null) {
final AuthScheme authScheme = (AuthScheme)
context.getAttribute("http-preemptive-auth");
final CredentialsProvider credsProvider = (CredentialsProvider)
context.getAttribute(ClientContext.CREDS_PROVIDER);
final HttpHost targetHost = (HttpHost)
context.getAttribute(ExecutionContext.HTTP_TARGET_HOST);
if (authScheme != null) {
final Credentials creds = credsProvider.getCredentials(new
AuthScope(targetHost.getHostName(), targetHost.getPort()));
if (creds != null) {
httpAuthState.setAuthScheme(authScheme);
httpAuthState.setCredentials(creds);
}
}
}
}
}
private static class PersistentAuth implements HttpResponseInterceptor {
public void process(final HttpResponse response, final HttpContext
context) throws org.apache.http.HttpException, IOException {
final AuthState httpAuthState = (AuthState)
context.getAttribute(ClientContext.TARGET_AUTH_STATE);
if (httpAuthState != null) {
final AuthScheme authScheme = httpAuthState.getAuthScheme();
context.setAttribute("http-preemptive-auth", authScheme);
}
}
}
So my questions basically are:
1) What to do about the fact that not all implementations seem to be
connection based?
2) Is there a way to send preemptive auth per request even if the scheme
says it's connection based?
Regards,
Sebastiaan
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
Sebastiaan van Erk wrote:
> Hi Oleg,
>
> Oleg Kalnichevski wrote:
>> Sebastiaan van Erk wrote:
>>
>>> Hi Oleg,
>>>
>>> Thanks for adding this. I'm currently a bit stuck on the caching of
>>> the tickets, which really needs to be fixed, but it looks like I'll
>>> have to dive into protocols/APIs deeply (JAAS, Java GSSAPI, SPNEGO)
>>> to figure it out.
>>>
>>> There is however one thing about the SPENGO authentication protocol
>>> that does not yet fit nicely into the httpclient API, namely, if you
>>> look at the diagram:
>>>
>>> http://issues.apache.org/jira/secure/attachment/12419383/SPNEGO_cropped.png
>>>
>>>
>>> What you see is a series of requests back and forth, with the last
>>> response containing the final negotiation token NOT having a response
>>> code of 401. In the diagram it's a 200, but in my case (with the
>>> redirect), it was a 3xx. In any case, the token should go back into
>>> the authentication scheme.
>>>
>>
>> This is somewhat similar to NTLM authentication, where the final
>> response code may also be 3xx, so HttpClient should be able to handler
>> such situations, worst case with some API extensions.
>>
>>
>>> BTW, I quickly hacked a response inteceptor which would do this for
>>> me (it was a hack, because it just called authenticate() again with
>>> the token and a null HttpRequest (since you don't have a request in
>>> the response interceptor) and at least GSSAPI was able to complete
>>> the negotiation. I did this because I was hoping this would solve the
>>> ticket caching problem, i.e, hoping that the tickets would be
>>> "committed" if the negotiation completed, but unfortunately this was
>>> not the case.
>>>
>>> I don't really know the authentication API should look to support
>>> this protocol... and it might in the end not really be necessary,
>>> except perhaps for mutual authentication.
>>>
>>> I'm going to look into the SPNEGO/GSSAPI stuff now to fix the
>>> caching, so I'm still on this. I just wanted to keep you posted.
>>>
>>> Regards,
>>> Sebastiaan
>>
>> Keep us posted on the progress.
>
> I working code including caching, but there is still a bunch of smaller
> issues which are still up in the air. I can post the code I've got so
> far, should I make a new JIRA issue for this, or add it to 523?
>
> The current status is:
>
> - Both http auth and proxy auth work.
>
> - The mutual auth works now, with a response interceptor specific for
> the Negotiate scheme. Perhaps this could somehow be integrated into an
> API change (in NegotiateScheme I added a
> "completeAuthentication(HttpContext) method which is called from the
> response interceptor after it calls processToken with the final token).
>
> - I can get the caching to work now, turns out this is weirdness in the
> JDK kerberos implementation. You can do 1 of 2 things:
> a) set useSubjectCredentialsOnly to false. In this case the ticket
> cache of the OS can be used to get the TGT, but service tickets are not
> read from here and NOTHING is cached. Terrible performance, but no
> double login required (if a TGT is already present, you don't have to
> type your password).
> b) set useSubjectCredentialsOnly to true. In this case you must sign
> on yourself with JAAS and a LoginContext and explicitly execute the http
> client methods in a Subject.doAsPriveleged block, which is annoying. You
> have to provide credentials since Java won't look in the ticket cache,
> so you need to enter the credentials to get a TGT. Fortunately it DOES
> cache credentials with the Subject. Since it's single sign on (once in
> the application combined with Subject.doAsPrivileged calls), the
> credentials used by the AuthScheme are dummy credentials (by that time,
> you're already logged in).
> I can't do anything about any of this, it's the way the Java Kerberos
> implementation works, so the only thing I can think of is adding an
> example using JAAS and Subject.doAsPrivileged and explain the
> benefits/problems with each approach in the example comments.
>
> - I haven't looked into the preemptive stuff yet.
>
> - The negotatiate scheme is connection based according to the docs I can
> find online, but my mod_auth_krb in apache doesn't seem to agree, so
> with each request I get another 401 and another negotiate cycle.
> HttpClient correctly does not try to reauthenticate, so I think this is
> the module's fault. Anyway, http client does reauthenticate after the
> 401, so it works.
>
> Regards,
> Sebastiaan
>
Hi Sebastiaan
I am glad you have been making progress with fixing SPNEGO issues. I
would like to suggest the following way forward. Submit your changes in
a series of relatively small, incremental patches. Start with more
important issues first. I'll be reviewing those patches and trying to
find ways to adapt the existing API to the peculiarities of Kerberos
authentication. Please also consider investing some time into
contributing additional content for the Kerberos related sections of the
HttpClient tutorial, especially to help deal with JDK implementation
weirdness and explain various trade-offs. Feel free to re-use the same
JIRA ticket or open new ones as you see fit.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi Oleg,
Oleg Kalnichevski wrote:
> Sebastiaan van Erk wrote:
>
>> Hi Oleg,
>>
>> Thanks for adding this. I'm currently a bit stuck on the caching of
>> the tickets, which really needs to be fixed, but it looks like I'll
>> have to dive into protocols/APIs deeply (JAAS, Java GSSAPI, SPNEGO) to
>> figure it out.
>>
>> There is however one thing about the SPENGO authentication protocol
>> that does not yet fit nicely into the httpclient API, namely, if you
>> look at the diagram:
>>
>> http://issues.apache.org/jira/secure/attachment/12419383/SPNEGO_cropped.png
>>
>>
>> What you see is a series of requests back and forth, with the last
>> response containing the final negotiation token NOT having a response
>> code of 401. In the diagram it's a 200, but in my case (with the
>> redirect), it was a 3xx. In any case, the token should go back into
>> the authentication scheme.
>>
>
> This is somewhat similar to NTLM authentication, where the final
> response code may also be 3xx, so HttpClient should be able to handler
> such situations, worst case with some API extensions.
>
>
>> BTW, I quickly hacked a response inteceptor which would do this for me
>> (it was a hack, because it just called authenticate() again with the
>> token and a null HttpRequest (since you don't have a request in the
>> response interceptor) and at least GSSAPI was able to complete the
>> negotiation. I did this because I was hoping this would solve the
>> ticket caching problem, i.e, hoping that the tickets would be
>> "committed" if the negotiation completed, but unfortunately this was
>> not the case.
>>
>> I don't really know the authentication API should look to support this
>> protocol... and it might in the end not really be necessary, except
>> perhaps for mutual authentication.
>>
>> I'm going to look into the SPNEGO/GSSAPI stuff now to fix the caching,
>> so I'm still on this. I just wanted to keep you posted.
>>
>> Regards,
>> Sebastiaan
>
> Keep us posted on the progress.
I working code including caching, but there is still a bunch of smaller
issues which are still up in the air. I can post the code I've got so
far, should I make a new JIRA issue for this, or add it to 523?
The current status is:
- Both http auth and proxy auth work.
- The mutual auth works now, with a response interceptor specific for
the Negotiate scheme. Perhaps this could somehow be integrated into an
API change (in NegotiateScheme I added a
"completeAuthentication(HttpContext) method which is called from the
response interceptor after it calls processToken with the final token).
- I can get the caching to work now, turns out this is weirdness in the
JDK kerberos implementation. You can do 1 of 2 things:
a) set useSubjectCredentialsOnly to false. In this case the ticket
cache of the OS can be used to get the TGT, but service tickets are not
read from here and NOTHING is cached. Terrible performance, but no
double login required (if a TGT is already present, you don't have to
type your password).
b) set useSubjectCredentialsOnly to true. In this case you must sign on
yourself with JAAS and a LoginContext and explicitly execute the http
client methods in a Subject.doAsPriveleged block, which is annoying. You
have to provide credentials since Java won't look in the ticket cache,
so you need to enter the credentials to get a TGT. Fortunately it DOES
cache credentials with the Subject. Since it's single sign on (once in
the application combined with Subject.doAsPrivileged calls), the
credentials used by the AuthScheme are dummy credentials (by that time,
you're already logged in).
I can't do anything about any of this, it's the way the Java Kerberos
implementation works, so the only thing I can think of is adding an
example using JAAS and Subject.doAsPrivileged and explain the
benefits/problems with each approach in the example comments.
- I haven't looked into the preemptive stuff yet.
- The negotatiate scheme is connection based according to the docs I can
find online, but my mod_auth_krb in apache doesn't seem to agree, so
with each request I get another 401 and another negotiate cycle.
HttpClient correctly does not try to reauthenticate, so I think this is
the module's fault. Anyway, http client does reauthenticate after the
401, so it works.
Regards,
Sebastiaan
> Cheers
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
Sebastiaan van Erk wrote:
> Hi Oleg,
>
> Thanks for adding this. I'm currently a bit stuck on the caching of the
> tickets, which really needs to be fixed, but it looks like I'll have to
> dive into protocols/APIs deeply (JAAS, Java GSSAPI, SPNEGO) to figure it
> out.
>
> There is however one thing about the SPENGO authentication protocol that
> does not yet fit nicely into the httpclient API, namely, if you look at
> the diagram:
>
> http://issues.apache.org/jira/secure/attachment/12419383/SPNEGO_cropped.png
>
> What you see is a series of requests back and forth, with the last
> response containing the final negotiation token NOT having a response
> code of 401. In the diagram it's a 200, but in my case (with the
> redirect), it was a 3xx. In any case, the token should go back into the
> authentication scheme.
>
This is somewhat similar to NTLM authentication, where the final
response code may also be 3xx, so HttpClient should be able to handler
such situations, worst case with some API extensions.
> BTW, I quickly hacked a response inteceptor which would do this for me
> (it was a hack, because it just called authenticate() again with the
> token and a null HttpRequest (since you don't have a request in the
> response interceptor) and at least GSSAPI was able to complete the
> negotiation. I did this because I was hoping this would solve the ticket
> caching problem, i.e, hoping that the tickets would be "committed" if
> the negotiation completed, but unfortunately this was not the case.
>
> I don't really know the authentication API should look to support this
> protocol... and it might in the end not really be necessary, except
> perhaps for mutual authentication.
>
> I'm going to look into the SPNEGO/GSSAPI stuff now to fix the caching,
> so I'm still on this. I just wanted to keep you posted.
>
> Regards,
> Sebastiaan
Keep us posted on the progress.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
Oleg Kalnichevski wrote:
> Sebastiaan van Erk wrote:
>> Oleg Kalnichevski wrote:
>>> Oleg Kalnichevski wrote:
>>>> Sebastiaan van Erk wrote:
>>>>> 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()) {
>>>>>
>>>>> init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
>>>>> "") );
>>>>> } 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]+$", "");
>>>>> }
>>>>> init(host);
>>>>>
>>>>> 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 {
>>>>> processChallenges(challenges,
>>>>> 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.
>>>>>
>>>>> Regards,
>>>>> Sebastiaan
>>>>>
>>>>
>>>> Hi Sebastiaan
>>>>
>>>> This looks nasty. The usual way of obtaining contextual details in
>>>> HttpClient is by examining attributes of the HttpContext instance
>>>> associated with the request being executed. The trouble is that auth
>>>> schemes factories presently have no means of getting hold of the
>>>> HttpContext.
>>>>
>>>> One possibility of fixing it would be extending or replacing the
>>>> AuthSchemeFactory with something better.
>>>>
>>>> ---
>>>> public interface BetterAuthSchemeFactory extends AuthSchemeFactory {
>>>>
>>>> AuthScheme newInstance(HttpContext context, HttpParams params);
>>>>
>>>> }
>>>> ---
>>>>
>>>> This is double but is far from trivial if 100% binary compatibility
>>>> with 4.0 is to be retained.
>>>>
>>>> Feel free to go ahead and open a change request in JIRA for this issue.
>>>>
>>>> Oleg
>>>>
>>>
>>> Probably a better alternative would be something like that
>>>
>>> ---------
>>> /**
>>> * This interface represents an extended authentication scheme
>>> * that requires access to {@link HttpContext} in order to
>>> * generate an authorization string.
>>> *
>>> * @since 4.1
>>> */
>>>
>>> public interface ContextAwareAuthScheme extends AuthScheme {
>>>
>>> /**
>>> * Produces an authorization string for the given set of
>>> * {@link Credentials}.
>>> *
>>> * @param credentials The set of credentials to be used for
>>> athentication
>>> * @param request The request being authenticated
>>> * @param context HTTP context
>>> * @throws AuthenticationException if authorization string cannot
>>> * be generated due to an authentication failure
>>> *
>>> * @return the authorization string
>>> */
>>> Header authenticate(
>>> Credentials credentials,
>>> HttpRequest request,
>>> HttpContext context) throws AuthenticationException;
>>>
>>> }
>>>
>>> ---------
>>>
>>> Oleg
>>
>> Hi Oleg,
>>
>> The ContextAwareAuthScheme looks perfect for the job.
>>
>> Should I open a JIRA issue for it?
>>
>
> Yes, you should
>
>> How will binary compatibility be maintained? An instanceof check at
>> the location where AuthScheme is used at the moment?
>>
>
> Yep
>
> Oleg
Hi Oleg,
Thanks for adding this. I'm currently a bit stuck on the caching of the
tickets, which really needs to be fixed, but it looks like I'll have to
dive into protocols/APIs deeply (JAAS, Java GSSAPI, SPNEGO) to figure it
out.
There is however one thing about the SPENGO authentication protocol that
does not yet fit nicely into the httpclient API, namely, if you look at
the diagram:
http://issues.apache.org/jira/secure/attachment/12419383/SPNEGO_cropped.png
What you see is a series of requests back and forth, with the last
response containing the final negotiation token NOT having a response
code of 401. In the diagram it's a 200, but in my case (with the
redirect), it was a 3xx. In any case, the token should go back into the
authentication scheme.
BTW, I quickly hacked a response inteceptor which would do this for me
(it was a hack, because it just called authenticate() again with the
token and a null HttpRequest (since you don't have a request in the
response interceptor) and at least GSSAPI was able to complete the
negotiation. I did this because I was hoping this would solve the ticket
caching problem, i.e, hoping that the tickets would be "committed" if
the negotiation completed, but unfortunately this was not the case.
I don't really know the authentication API should look to support this
protocol... and it might in the end not really be necessary, except
perhaps for mutual authentication.
I'm going to look into the SPNEGO/GSSAPI stuff now to fix the caching,
so I'm still on this. I just wanted to keep you posted.
Regards,
Sebastiaan
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
Oleg Kalnichevski wrote:
> Sebastiaan van Erk wrote:
>> Oleg Kalnichevski wrote:
>>> Oleg Kalnichevski wrote:
>>>> Sebastiaan van Erk wrote:
>>>>> 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()) {
>>>>>
>>>>> init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
>>>>> "") );
>>>>> } 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]+$", "");
>>>>> }
>>>>> init(host);
>>>>>
>>>>> 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 {
>>>>> processChallenges(challenges,
>>>>> 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.
>>>>>
>>>>> Regards,
>>>>> Sebastiaan
>>>>>
>>>>
>>>> Hi Sebastiaan
>>>>
>>>> This looks nasty. The usual way of obtaining contextual details in
>>>> HttpClient is by examining attributes of the HttpContext instance
>>>> associated with the request being executed. The trouble is that auth
>>>> schemes factories presently have no means of getting hold of the
>>>> HttpContext.
>>>>
>>>> One possibility of fixing it would be extending or replacing the
>>>> AuthSchemeFactory with something better.
>>>>
>>>> ---
>>>> public interface BetterAuthSchemeFactory extends AuthSchemeFactory {
>>>>
>>>> AuthScheme newInstance(HttpContext context, HttpParams params);
>>>>
>>>> }
>>>> ---
>>>>
>>>> This is double but is far from trivial if 100% binary compatibility
>>>> with 4.0 is to be retained.
>>>>
>>>> Feel free to go ahead and open a change request in JIRA for this issue.
>>>>
>>>> Oleg
>>>>
>>>
>>> Probably a better alternative would be something like that
>>>
>>> ---------
>>> /**
>>> * This interface represents an extended authentication scheme
>>> * that requires access to {@link HttpContext} in order to
>>> * generate an authorization string.
>>> *
>>> * @since 4.1
>>> */
>>>
>>> public interface ContextAwareAuthScheme extends AuthScheme {
>>>
>>> /**
>>> * Produces an authorization string for the given set of
>>> * {@link Credentials}.
>>> *
>>> * @param credentials The set of credentials to be used for
>>> athentication
>>> * @param request The request being authenticated
>>> * @param context HTTP context
>>> * @throws AuthenticationException if authorization string cannot
>>> * be generated due to an authentication failure
>>> *
>>> * @return the authorization string
>>> */
>>> Header authenticate(
>>> Credentials credentials,
>>> HttpRequest request,
>>> HttpContext context) throws AuthenticationException;
>>>
>>> }
>>>
>>> ---------
>>>
>>> Oleg
>>
>> Hi Oleg,
>>
>> The ContextAwareAuthScheme looks perfect for the job.
>>
>> Should I open a JIRA issue for it?
>>
>
> Yes, you should
>
>> How will binary compatibility be maintained? An instanceof check at
>> the location where AuthScheme is used at the moment?
>>
>
> Yep
>
> Oleg
>
>> Regards,
>> Sebastiaan
https://issues.apache.org/jira/browse/HTTPCLIENT-901
Regards,
Sebastiaan
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
Sebastiaan van Erk wrote:
> Oleg Kalnichevski wrote:
>> Oleg Kalnichevski wrote:
>>> Sebastiaan van Erk wrote:
>>>> 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()) {
>>>>
>>>> init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
>>>> "") );
>>>> } 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]+$", "");
>>>> }
>>>> init(host);
>>>>
>>>> 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 {
>>>> processChallenges(challenges,
>>>> 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.
>>>>
>>>> Regards,
>>>> Sebastiaan
>>>>
>>>
>>> Hi Sebastiaan
>>>
>>> This looks nasty. The usual way of obtaining contextual details in
>>> HttpClient is by examining attributes of the HttpContext instance
>>> associated with the request being executed. The trouble is that auth
>>> schemes factories presently have no means of getting hold of the
>>> HttpContext.
>>>
>>> One possibility of fixing it would be extending or replacing the
>>> AuthSchemeFactory with something better.
>>>
>>> ---
>>> public interface BetterAuthSchemeFactory extends AuthSchemeFactory {
>>>
>>> AuthScheme newInstance(HttpContext context, HttpParams params);
>>>
>>> }
>>> ---
>>>
>>> This is double but is far from trivial if 100% binary compatibility
>>> with 4.0 is to be retained.
>>>
>>> Feel free to go ahead and open a change request in JIRA for this issue.
>>>
>>> Oleg
>>>
>>
>> Probably a better alternative would be something like that
>>
>> ---------
>> /**
>> * This interface represents an extended authentication scheme
>> * that requires access to {@link HttpContext} in order to
>> * generate an authorization string.
>> *
>> * @since 4.1
>> */
>>
>> public interface ContextAwareAuthScheme extends AuthScheme {
>>
>> /**
>> * Produces an authorization string for the given set of
>> * {@link Credentials}.
>> *
>> * @param credentials The set of credentials to be used for
>> athentication
>> * @param request The request being authenticated
>> * @param context HTTP context
>> * @throws AuthenticationException if authorization string cannot
>> * be generated due to an authentication failure
>> *
>> * @return the authorization string
>> */
>> Header authenticate(
>> Credentials credentials,
>> HttpRequest request,
>> HttpContext context) throws AuthenticationException;
>>
>> }
>>
>> ---------
>>
>> Oleg
>
> Hi Oleg,
>
> The ContextAwareAuthScheme looks perfect for the job.
>
> Should I open a JIRA issue for it?
>
Yes, you should
> How will binary compatibility be maintained? An instanceof check at the
> location where AuthScheme is used at the moment?
>
Yep
Oleg
> Regards,
> Sebastiaan
>
>> ---------------------------------------------------------------------
>> 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
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
Oleg Kalnichevski wrote:
> Oleg Kalnichevski wrote:
>> Sebastiaan van Erk wrote:
>>> 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()) {
>>>
>>> init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
>>> "") );
>>> } 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]+$", "");
>>> }
>>> init(host);
>>>
>>> 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 {
>>> processChallenges(challenges,
>>> 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.
>>>
>>> Regards,
>>> Sebastiaan
>>>
>>
>> Hi Sebastiaan
>>
>> This looks nasty. The usual way of obtaining contextual details in
>> HttpClient is by examining attributes of the HttpContext instance
>> associated with the request being executed. The trouble is that auth
>> schemes factories presently have no means of getting hold of the
>> HttpContext.
>>
>> One possibility of fixing it would be extending or replacing the
>> AuthSchemeFactory with something better.
>>
>> ---
>> public interface BetterAuthSchemeFactory extends AuthSchemeFactory {
>>
>> AuthScheme newInstance(HttpContext context, HttpParams params);
>>
>> }
>> ---
>>
>> This is double but is far from trivial if 100% binary compatibility
>> with 4.0 is to be retained.
>>
>> Feel free to go ahead and open a change request in JIRA for this issue.
>>
>> Oleg
>>
>
> Probably a better alternative would be something like that
>
> ---------
> /**
> * This interface represents an extended authentication scheme
> * that requires access to {@link HttpContext} in order to
> * generate an authorization string.
> *
> * @since 4.1
> */
>
> public interface ContextAwareAuthScheme extends AuthScheme {
>
> /**
> * Produces an authorization string for the given set of
> * {@link Credentials}.
> *
> * @param credentials The set of credentials to be used for
> athentication
> * @param request The request being authenticated
> * @param context HTTP context
> * @throws AuthenticationException if authorization string cannot
> * be generated due to an authentication failure
> *
> * @return the authorization string
> */
> Header authenticate(
> Credentials credentials,
> HttpRequest request,
> HttpContext context) throws AuthenticationException;
>
> }
>
> ---------
>
> Oleg
Hi Oleg,
The ContextAwareAuthScheme looks perfect for the job.
Should I open a JIRA issue for it?
How will binary compatibility be maintained? An instanceof check at the
location where AuthScheme is used at the moment?
Regards,
Sebastiaan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
Oleg Kalnichevski wrote:
> Sebastiaan van Erk wrote:
>> 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()) {
>>
>> init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
>> "") );
>> } 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]+$", "");
>> }
>> init(host);
>>
>> 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 {
>> processChallenges(challenges,
>> 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.
>>
>> Regards,
>> Sebastiaan
>>
>
> Hi Sebastiaan
>
> This looks nasty. The usual way of obtaining contextual details in
> HttpClient is by examining attributes of the HttpContext instance
> associated with the request being executed. The trouble is that auth
> schemes factories presently have no means of getting hold of the
> HttpContext.
>
> One possibility of fixing it would be extending or replacing the
> AuthSchemeFactory with something better.
>
> ---
> public interface BetterAuthSchemeFactory extends AuthSchemeFactory {
>
> AuthScheme newInstance(HttpContext context, HttpParams params);
>
> }
> ---
>
> This is double but is far from trivial if 100% binary compatibility with
> 4.0 is to be retained.
>
> Feel free to go ahead and open a change request in JIRA for this issue.
>
> Oleg
>
Probably a better alternative would be something like that
---------
/**
* This interface represents an extended authentication scheme
* that requires access to {@link HttpContext} in order to
* generate an authorization string.
*
* @since 4.1
*/
public interface ContextAwareAuthScheme extends AuthScheme {
/**
* Produces an authorization string for the given set of
* {@link Credentials}.
*
* @param credentials The set of credentials to be used for
athentication
* @param request The request being authenticated
* @param context HTTP context
* @throws AuthenticationException if authorization string cannot
* be generated due to an authentication failure
*
* @return the authorization string
*/
Header authenticate(
Credentials credentials,
HttpRequest request,
HttpContext context) throws AuthenticationException;
}
---------
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
Sebastiaan van Erk wrote:
> 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()) {
>
> init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
> "") );
> } 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]+$", "");
> }
> init(host);
>
> 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 {
> processChallenges(challenges,
> 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.
>
> Regards,
> Sebastiaan
>
Hi Sebastiaan
This looks nasty. The usual way of obtaining contextual details in
HttpClient is by examining attributes of the HttpContext instance
associated with the request being executed. The trouble is that auth
schemes factories presently have no means of getting hold of the
HttpContext.
One possibility of fixing it would be extending or replacing the
AuthSchemeFactory with something better.
---
public interface BetterAuthSchemeFactory extends AuthSchemeFactory {
AuthScheme newInstance(HttpContext context, HttpParams params);
}
---
This is double but is far from trivial if 100% binary compatibility with
4.0 is to be retained.
Feel free to go ahead and open a change request in JIRA for this issue.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
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()) {
init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
"") );
} 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]+$", "");
}
init(host);
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 {
processChallenges(challenges,
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.
Regards,
Sebastiaan
> 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:85.147.225.232 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
>
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
Oleg Kalnichevski wrote:
> Sebastiaan van Erk wrote:
>> 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.
>>
>
> hhhm. HttpClient should be doing exactly that
>
> http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/client/DefaultRequestDirector.html#999
Ah, but this is only if the target host is different. The problem here
is that the target host is the same, but the it's a different resource,
so the negotiation must begin anew... (In my test, the redirect is from
http://tunneltest.servoy.com/private ->
http://tunneltest.servoy.com/private/
>> 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.
>>
>
> Take a look at how preemptive Digest auth works in 4.1. It might be
> similar to what you want:
>
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java
Thanks for the tip. Will look at it right after I fix the ticket caching
issue.
Regards,
Sebastiaan
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
Sebastiaan van Erk wrote:
> 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.
>
hhhm. HttpClient should be doing exactly that
http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/client/DefaultRequestDirector.html#999
>
> 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.
>
Take a look at how preemptive Digest auth works in 4.1. It might be
similar to what you want:
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
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.
Regards,
Sebastiaan
> 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:85.147.225.232 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
>
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
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:85.147.225.232 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
Re: Kerberos proxy authentication issue
Posted by Sebastiaan van Erk <se...@sebster.com>.
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
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:85.147.225.232 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
>
Re: Kerberos proxy authentication issue
Posted by Oleg Kalnichevski <ol...@apache.org>.
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:85.147.225.232
> 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