hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: custom authentication with slide and httpclient
Date Mon, 07 Feb 2005 20:45:52 GMT
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: httpclient-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
> >  
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 


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


Mime
View raw message