cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: HTTP Basic Authentication Is there hope?
Date Mon, 12 Feb 2007 21:00:49 GMT
Daniel Kulp wrote:
> On Sunday 11 February 2007 16:21, Dan Diephouse wrote:
>   
>> As a side note, do we really think http chunking should be on by default?
>> We ended up making users having to turn it on in XFire because of
>> interoperability issues with various HTTP servers. So it makes me nervous
>> to default to having chunking on.
>>     
>
> If chunking is not turned off (or redirects turned on BTW), then streaming is 
> effectively disabled and performance for large messages drops significantly 
> (and memory usage goes way up).   The HTTPUrlConnection object buffers the 
> entire message into a byte[] so that it can calculate the Content-Length 
> header (if one isn't specified which we don't calculate) or resend if it gets 
> a 30# response code.   With chunking, the Content-Lenght header is not needed 
> so if redirect support is off, it can stream directly.   However, that also 
> breaks the 401 resend.
>
>
> What we could do is disable chunking if there is a 401 callback registered and 
> the we're already not authenticated.  If there is a basic auth header to go 
> out (AuthenticationPolicy object filled out), keep the chunking.   
>   

Can chunking be turned on a connection after an authentication? Is that 
allowed?

>> The java.net.HttpURLConnection does have an authenticator scheme that
>>     
>>> allows "automatic" use of Password Authentication,
>>> java.net.Authenticator. This Authenticator, (apparently only one per
>>> JVM), has an interface with which to query certain aspects of the site
>>> "requesting" authentication, such as IP address, port numbers, URL, etc.
>>> This object does provide differentiation of figuring out which username
>>> and passwords to send, but is slightly lacking in deciding trust whether
>>> to send them or not.
>>>
>>> The big question is, can we do better than this? Can we organize
>>> something in CXF that will allow us to use security in a good way? First
>>> establishing trust before sending sensitive information? Can we do this
>>> without solely programming everything into an XML file?
>>>
>>> Even this java.net.Authenticator is woefully inadequate as there is now
>>> way too look up an SSL authentication on the HttpURLConnection.
>>>
>>> I don't imagine that the use of HttpURLConnection will go away inside
>>> CXF, but there should be some better way to "configure" or at least
>>> dynamically direct the HTTPConduit in use for a particular endpoint.
>>> Would it be beneficial to the team for me to spend time on proposing a
>>> good security solution?
>>>       
>
>
> Couple caveats/use cases that must be supported:
> 1) If there isn't a callback and we get a 401,  we must throw a proper 
> exception that is propagated back with all useful information to the user.
>   

That currently does not happen because the HttpURLConnection 
implementation hides the needed information. I am now looking into the 
Jakara commons HTTPClient, which looks quite promising, if it works like 
it web page says.

> 2) If the user has specified a username/password programatically (ex: 
> BindingProvider keys from JAX-WS frontend), we need to put them on the wire 
> immediately, even if it's just http. (spec compliance)
>   

Okay. If that's what the user wants, that's what he gets! :)

> I'm not going to pretend to understand half of what this thread is talking 
> about (I'm not a security expert by any means), but the "simple" usecases 
> need to be the defaults due to JAX-WS spec compliance.

Surely, please keep us in line on these issues. I am not all that 
familiar with JAX-WS, but I'm learning.

Cheers,
-Polar

Mime
View raw message