On Mon, 2015-04-13 at 22:46 +0200, Michael Osipov wrote: > Hi folks, > > I'd like to you to update on the status of my rewrite challenge: > > It did not turn out to be as easy as I have assumed. I debugged a lot of > stuff, read the code, etc. HttpClient is well implementing RFC 2617 auth > schemes which are all request-based (stateless), challenge-response > (server-first) and one way. > > Unfortunately this does not work for *any* GSS-API/SSPI mech(s) (SPNEGO, > Kerberos, NTLM) which are connection-based (stateful), > challenge-response (but *client-first!*, consider: "WWW-Authenticate: > Negotiate/Kerberos/NTLM" is /not/ a challenge) and optionally mutual > (WWW-Athenticate on non-401/407). This is a complete contradiction to > RFC 2617. > > I wrote a simple PingPingAuthenticator (in Tomcat) and a PingPingScheme > which do the following on the connection: > > C: GET /secure > S: HTTP/1.1 401 Unauthorized > S: WWW-Authenticate: PingPong > #(1) Client will discard response body > C: GET /secure > C: Authorization: PingPong 1 > S: HTTP/1.1 401 Unauthorized > S: WWW-Authenticate: PingPong 2 > #(2) Client will discard response body > C: GET /secure > C: Authorization: PingPong 3 > S: HTTP/1.1 200 OK > #(2) Client has to read in the header, validate and the use response body > S: WWW-Authenticate: PingPong GameOver > S: Response... > > See: http://tools.ietf.org/html/rfc4559#section-5 > > I see that the code completely ignores "PingPong GameOver". Oleg's hack > won't work because #processResponse cannot throw an > AuthenticationException in the case that the (opaque) token is invalid > and consume non-401/407 response. Even if that would work, > MainClientExec would need to know first when to pass that in again by > calling authenticator#isAuthenticationRequested along with a proper > AuthenticationStrategy implementation but after that MainExecClient > consumes the HttpEntity. It assumes that auth is unconditionally in > handshake state. > > Additionally, HttpAuthenticator probably requires some rewrite to > accommodate all of those changes (inversion). > > Currently, I do not know how to solve this problem best. It might be > necessary to introduce two new methods to AuthScheme > > 1. #isClientFirst > 2. #isMutual > > but this still has to be determined. > > In advent of a suitable replacement for Digest, there is also a RFC > draft for SCRAM-SHA-1 over HTTP [1]. If someone considers to implement > that in HttpClient, forget it. It is client-first (if required) and mutual. > > Currently, I *do not* recommend using the current implementations at > all. Rather create a JGSS/SSPI context manually, pass tokens and > establish the context. > > This is -- in short -- it for now. > > Comments, implementation tips, other thoughts, etc. are highly welcome. > > I will keep you updated, > > Michael
Michael, Probably we have to move resolution of this issue to 5.0 given how disruptive these changes are likely to be. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
