cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Discuss change http authorization handling to be strategy based
Date Wed, 17 Nov 2010 21:28:33 GMT
On Monday 15 November 2010 6:47:53 pm Christian Schneider wrote:
> Am 15.11.2010 21:34, schrieb Daniel Kulp:
> > Well, I guess here would be my "requirements":
> > 
> > 1) "Out of the box", basic auth needs to "just work".  If the user sets
> > the username and password and nothing is configured in, the basic auth
> > stuff should automatically turn on preemptively.
> > 
> > 2) Streaming - related to (1), when the username/password is set with
> > basic auth, it  cannot break streaming.
> > 
> > 3) If the other auth mechanisms support streaming, we should keep it
> > enabled. However, some of them don't allow for the streaming.
> > 
> > 4) Obviously, if something IS configured in, that should just work as
> > well.
> > 
> > :-)
> 
> I did not really understand this one? what do you mean by "configured
> in"? Do you mean the HttpAuthsupplier?

Well, I mean if the user somehow, via some config of some sort, said "use 
Digest", it would just use Digest and not do the pre-emtive BasicAuth.


> I am not so sure about this construction. It somehow looks strange and I
> have never seen this in use in practice.
> 
> >> We could do it upfront and then only give the conduit one strategy
> >> or we could do it later and give the conduit a strategy that decides for
> >> each case which real stratgy to use.
> > 
> > The streaming requirement kind of removes the second option.   Once we
> > get the 401 back, the streaming is stopped and the original message is
> > gone.   If the user specifically turns off streaming, OK, we can do
> > something smart.
> > 
> > Dan
> 
> I think this does not rule out the second option. After looking into the
> problem a little deeper I even think we can only decide the actual
> authentication mechanism after the construction of the conduit.
> The reason is that you can set an auth policy on the message and it
> should override the authpolicy in the config.

Right.   But only up to a certain point.  :-)  I'd be OK with only allowing 
changes to the auth policy being allowed only in interceptors prior to the 
prepare being called.  (PREPARE_SEND phase)


> So I guess it could work to have a class that decides which strategy to
> use based on the effective authpolicy (config merged with that from the
> message). This class would for example decide to use Spnego with
> preemptive authentication. In this case streaming could still work.

Sure. 


> I also have another question. There is the class CxfAuthenticator. In
> this class the Authenticator.setDefault is set. So this also does some
> kind of authentication. Do you know how this works together with the
> rest of the authentication code? I think this could perhaps be old code
> and be redundant now. In any case it only seems to support basic auth
> for server and proxy.

Actually, this is there for two use cases:

1) For NTLM authentication that is built into the JDK on Java6.  When the JDK 
sets up the TLS connection, it calls back into there to get the credentials it 
needs for the NTLM auth.   

2) Certain SSL tunnelling based Proxy servers - in this case, there isn't 
(with Java5, haven't checked Java6) to set the creds needed for the proxy.   
The callback is the only way.   See:
https://issues.apache.org/jira/browse/CXF-2223



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message