This page tracks the design goals of the complete redesign of the GSS-based authentication in HttpClient. Namely, implementation decisions, known issues, questions, testing, etc. All code will be developed in a separate branch.
Implemenation decisions are comprised of several blocks like interface implementations, exception handling, logging, etc.
AuthSchemeProvider
: merely a factory for creating AuthScheme
instances. Implemenation will be GSSBasedSchemeProvider
. It will take in one argument, the OID string of the desired authentication mechanism or simply the AuthScheme
name.AuthSchemeBase
(implements ContextAwareAuthScheme
): the implementation GSSBasedScheme
will take in one argument, the OID string of the desired authentication mechanism or simply the AuthScheme
. It will internally maintain a stateful GSSContext
for the authentication against a target or a proxy. Since the implementation itself does not know when it will be nulled and garbage collected, it will maintain its state internally and release the GSSContext
immediately upon successful completion or the first failure. This implemenation will not be threadsafe.Credentials
: this will be GSSBasedCredentials
and will take in a GSSCredential
. Useful if not the default GSSCredential
will be used. It is also necessary to create a GSSPrincipal
class which will wrap the GSSName
from the credential.UserTokenHandler
: TBD
TBD
TBD
GSSBasedScheme
, thus authentication can never be completed. It is highly likely that the HttpAuthenticator
needs to be changed. There must be a notion of isClientFirst
just as in SASL (RFC 4422, section 5, 2a).
CredentialsProvider
with an fake item must be set otherwise authentication is not triggered.Testing is comprised of two sections: unit tests and integration tests.
It has to be determined how one can reasonably mock GSS objects to test the new implementation.
Integeration tests will be performed in a corporate environment with the following setup:
Note Not all combinations can be tested. |
Concrete requests are still open.
MalformedChallengeException
not extend AuthenticationException
though it is documented for authentication purposes?MalformedChallengeException
signals syntax violation of some sort presenting the client from understanding the challenge whereas AuthenticationException
signals inability or unwillingness to respond to the challenge. To me these are different type of issues, but I am open to changing it in 5.0.ChallengeState
is quite confusing. Where is the state? This is merely a ChallengeHostType
.AuthCounterpartType
or some such in 4.5.ContextAwareAuthScheme
instance be reused?HttpContext
).HttpContext
be used concurrently?HttpContext
.
DefaultUserTokenHandler