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