hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Progress of HTTPCLIENT-1625 (2)
Date Tue, 14 Apr 2015 18:35:22 GMT
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message