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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
