You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Schneider Christian <Ch...@enbw.com> on 2010/11/15 16:26:44 UTC
Discuss change http authorization handling to be strategy based
Hi all,
I am currently working on https://issues.apache.org/jira/browse/CXF-3123 (Support Spnego/Kerberos authentication for http transport).
My first attempt was to use implement an AuthSupplier for this case. I thought AuthSupplier acts as a kind of strategy to implement auth support.
When I digged into the code I found that this is not really true. AuthSupplier seems to be used only in some cases and much other decisions are done in setHeadersByAuthorizationPolicy, setBasicAuthHeader, setProxyBasicAuthHeader, authorizationRetransmit. So it would be not so easy to add another authentication mechanism.
To clean this up I propose to refactor to a strategy based implementation with 3 currently strategies:
- BasicAuthStrategy
- DigestAuthStrategy
- SpnegoAuthStrategy
The conduit should do no detailed authentication handling at all. Instead it should delegate to the strategy to be used and let it do what is needed. Another problem is then of course how to choose the strategy to be used. 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.
Any ideas / opinions about this are very much welcome.
Best regards
Christian
Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching
Tel : +49-(0)721-63-15482
EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim ‑ HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
Re: Discuss change http authorization handling to be strategy based
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: Discuss change http authorization handling to be strategy based
Posted by Christian Schneider <ch...@die-schneider.net>.
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?
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.
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.
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.
Christian
--
----
http://www.liquid-reality.de
Re: Discuss change http authorization handling to be strategy based
Posted by Daniel Kulp <dk...@apache.org>.
Moving to dev@ as it's more of a dev@ discussion.
On Monday 15 November 2010 10:26:44 am Schneider Christian wrote:
> Hi all,
>
> I am currently working on https://issues.apache.org/jira/browse/CXF-3123
> (Support Spnego/Kerberos authentication for http transport). My first
> attempt was to use implement an AuthSupplier for this case. I thought
> AuthSupplier acts as a kind of strategy to implement auth support.
>
> When I digged into the code I found that this is not really true.
> AuthSupplier seems to be used only in some cases and much other decisions
> are done in setHeadersByAuthorizationPolicy, setBasicAuthHeader,
> setProxyBasicAuthHeader, authorizationRetransmit. So it would be not so
> easy to add another authentication mechanism.
>
> To clean this up I propose to refactor to a strategy based implementation
> with 3 currently strategies:
>
> - BasicAuthStrategy
> - DigestAuthStrategy
> - SpnegoAuthStrategy
>
> The conduit should do no detailed authentication handling at all.
Sure. That works for me. Originally, it just supported the BasicAuth stuff
internally with the AuthSupplier there to extend it. When the Digest stuff
was added, we added it as an AuthSupplier, but never really pulled the
BasicAuth stuff out.
> Instead
> it should delegate to the strategy to be used and let it do what is
> needed. Another problem is then of course how to choose the strategy to be
> used.
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.
:-)
> 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
>
> Any ideas / opinions about this are very much welcome.
>
> Best regards
>
> Christian
>
> Christian Schneider
> Informationsverarbeitung
> Business Solutions
> Handel und Dispatching
>
> Tel : +49-(0)721-63-15482
>
> EnBW Systeme Infrastruktur Support GmbH
> Sitz der Gesellschaft: Karlsruhe
> Handelsregister: Amtsgericht Mannheim ‑ HRB 108550
> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog