cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject HTTP Basic Authentication Is there hope?
Date Sun, 11 Feb 2007 17:13:27 GMT
The current way http auth is set up in CXF is to use Spring 
configuration to on HTTPConduit, like so in a file like "client.xml".

    <bean 
name="{http://apache.org/hello_world_soap_http}Greeter.http-conduit" 
abstract="true">    
        <property name="authorization">
            <value>
                <sec:authorization>
                    <sec:UserName>Polar</sec:UserName>
                    <sec:Password>querty</sec:Password>
                </sec:authorization>
            </value>
        </property>
    </bean>

This approach looks less like "having security" and more like "getting 
around the *problem* of security".

Aside from the *bad practice* of keeping user name/password combinations 
in unencrypted files, this approach is also subtly bad in that assumes 
that you know what servers you are going to apriori. The configuration 
of the http-conduit bean is not server specific, but type specific. I 
may very well have two different servers offering the same service. One 
trustworthy, and one rogue (collecting passwords). Confusion may ensue 
in a more dynamic environment, let's say if I get my WSDL port/endpoint 
information from an untrusted source like a UDDI server, or my dead 
grandmother. Another scenario is if I am building for example, an 
application that uses the same "standard" service offered by two 
different Banks, I can't use this approach unless I have the same 
username and password at both banks.

We would like to examine certain aspects of the endpoint before we start 
*exposing usernames and passwords to everybody* with a pretty flower. 
There is no apparent way to do this in CXF's use of HTTP.

Furthermore, the HTTP protocol requires that a 401 status be returned 
from the server if the authorization information is not supplied or 
incorrect. The 401 response comes back with authorization challenge 
information, namely the "realm" identifier, which CXF HTTP ignores.

Internally, CXF uses java.net.HttpURLConnection on the client side, 
which is really the implementation 
sun.net.www.protocol.http.HttpURLConnection. This implementation catches 
the 401 response message and attempts to authenticate [see below], 
however, it fails with the HTTPRetryException. This exception is caught 
and turned into a message fault, now allowing us to get any information. 
It fails oddly because the HTTPConduit's default is to "stream". 
Streaming is configurable on the endpoint http-conduit HTTPClientPolicy.

I can construct a complex graph of interceptors on the server side to 
send the 401 and the proper realm information. However, it fails on the 
client side in HttpURLConnection with an HTTPRetryException, on 
getInputStream, which is ignored by HTTPConduit. The error is "cannot 
retry due to server authentication while streaming".
 
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?

Cheers,
-Polar


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message