hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Progress of HTTPCLIENT-1625 (2)
Date Fri, 17 Apr 2015 11:02:49 GMT
Am 2015-04-14 um 20:35 schrieb Oleg Kalnichevski:
> 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.

I need to agree here, given than stuff will change anyway in 5.0, this 
is a good option to fix that in one go.

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message