hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Hamid <ar...@cornell.edu>
Subject Re: custom authentication with slide and httpclient
Date Mon, 07 Feb 2005 20:25:10 GMT
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: 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