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
