Hi Oleg,
The type of authentication I am implementing is in fact Kerberos. There is no secret key sent, etc. Kerberos has it's own replay/man-in-the-middle protections. I agree in principal that it is best to operate in accordance with existing standards and behavior (even if they do not match perfectly what oine requires), however I did not design this protocol, it has been in production successfully for years, and it is being used in multi-tier (i.e. no human involved) web services, so I doubt I have much ground to lobby for a challenge/response scheme (that would make things much more complicated with regard to stateless services that authenticate per-request...everything would have to be rechallenged every request, it's just not plausible). I can understand why something like this would not be specifically condoned ("only use if you know what you are doing") but does it actually have to be prohibited? Can I setAuthenticationPreemptive, and then explicitly set Credentials, without using CredentialsProvider? I think I tried this, but it may not have worked for the second reason I cited.
Thanks for the feedback, Aaron
Oleg Kalnichevski wrote:
Hi Aaron,
See my comments in-line
On Mon, 2005-02-07 at 10:49 -0500, Aaron Hamid wrote:
Hi folks, sorry for the cross posting but I think this issue is relevant to both projects.
<snip>
There are two problems I have found, one in http client, one in Slide. First, it seems that CredentialsProvider ONLY is called upon a challenge from the server (HttpMethodDirector, 'promptForCredentials'), and never pre-emptively, even if I setAuthenticationPreemptive(true). My expectation would be that if I set preemptive authentication than my registered CredentialsProvider should be called prior to the request being made. Our custom auth doesn't use an HTTP challenge, so the creds are required to be there to begin with.
I can explain this. The problem is that only Basic authentication can be used preemptively and required by HTTP spec for compatibility reasons. All other schemes either cannot be used preemptively (NTLM) or should not be used preemptively (Digest to some extent).
Firstly, challenge-less authentication schemes are inherently insecure, because they allow the authentication credentials to be sent to an unknown party. Even if the credentials are encrypted using a predefined encryption algorithm, one can still easily pull off a 'man in the middle' type of exploit.
Secondly, the so called 'expect: continue' handshake renders the preemptive authentication virtually superfluous. For a fairly small price one gains a lot in terms of security.
Bottom line, if your web server supports HTTP/1.1, which is a commonplace these days, disable the preemptive authentication, enable the 'expect: continue' handshake and live happily ever after.
In addition, it seems that the HTTP Method implementations of Slide use a default AuthState (in HttpMethodBase). Apparently it uses BASIC auth as the default scheme, and does not pick up the global defaults (I tried registering my parameters on the DefaultParams* singleton after discovering this, to see if they would be picked up, but they are not).
I do not know much about Slide's inner working, but I'll be willing to take a look at the Slide source code, should this be required.
I think the first quick fix is to update HttpMethodDirector so it uses CredentialsProvider preemptively (if one is defined, and setAuthenticationPreemptive is set).
See above.
I'm not sure how to handle the second problem because I am not thoroughly familiar with the design decisions and abstractions behind HttpClient and expected usage. I would think either the Slide WebdavResource should expose the HttpClient with the real AuthState it will use (I know I can get HttpClient through WebdavSession.getSessionInstance... but it appears the default AuthState in the Method "overrides" anything I set), or have the default authstate inherit global defaults (perhaps lazily).
See above.
Cheers,
Oleg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
