hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Progress of HTTPCLIENT-1625 (2)
Date Mon, 13 Apr 2015 20:46:51 GMT
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

[1] 
http://datatracker.ietf.org/doc/draft-melnikov-httpbis-scram-auth/?include_text=1

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


Mime
View raw message