On Mon, 2005-02-07 at 15:25 -0500, Aaron Hamid wrote: > Hi Oleg, > > The type of authentication I am implementing is in fact Kerberos.
OK, I see. The trouble is that currently Basic authentication scheme is hardwired. It cannot be substituted with any other scheme http://jakarta.apache.org/commons/httpclient/3.0/xref/org/apache/commons/httpclient/auth/AuthState.html#111 Please file a bug / feature request in Bugzilla and I'll provide a fix as soon as I can. Luckily (as far as I can tell at this point) the fix should be pretty straightforward and should not require any API changes Cheers, Oleg > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
