hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Kerberos proxy authentication issue
Date Sun, 20 Dec 2009 14:07:02 GMT
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


Mime
View raw message