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: [email protected]
For additional commands, e-mail: [email protected]
