You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2010/12/22 20:39:16 UTC
Request for feedback: Refactoring of HTTP client authentication
I have now refactored the authentication of the http transport so the
basic auth is now supported by DefaultBasicAuthSupplier. Spnego is now
also supported using a SpnegoAuthSupplier.
As I have changed some of the behaviour I would like to get some
feedback before committing this.
Please also see:
https://issues.apache.org/jira/browse/CXF-3216
Basic, Digest and Spnego / Kerberos auth can now be configured by simply
setting the AuthType in the AuthorizationPolicy. The HttpConduit then
creates a HttpAuthSupplier on the fly if none is configured explicitly.
Still an AuthoriationPolicy on the message overrides the
AuthorizationPolicy on the Conduit.
I have also added a system test for DigestAuthSupplier as I changed the
code and wanted to make sure it really works against a jetty insstance.
There are some possible compatibility issues with my patch:
* The first thing is that the HttpAuthSupplier is cached so it is
created only once. If you later change the Authtype the supplier
will stay the same. This can be solved by deleting the
authSupplier so it is recreated.
* The HttpAuthsupplier now overrides the AuthorizationPolicy on the
message. Before the AuthorizationPolicy on the message would
override the AuthSupplier. I don?t think anyone really would use this
* If the message content is to be cached is now only determined by
calling the requiresRequestCaching method on the authsupplier.
Before the authSupplier was also asked for
premptiveAuthentication. If this did not return null the message
was also cached. I think this is not necessary as the authsupplier
can still decide if caching is needed.
* Currently you can set authType and authorization on the
authorizationPolicy. This is then used to directly create the
authorization header. This is used by the old spnego interceptor I
added recently. I removed this feature as it is only really usable
in an interceptor and it can be done better by creating a custom
authSupplier
Additionally I would like to remove the feature of setting an
AuthorizationPolicy on the message. This would allow us to make the
authsuppliers independent of conduit and message in the future.
I also would like to introduce an authSupplier for proxy auth and
handling of 407 responses so we can support multi phase authentications
with a proxy.
--
----
http://www.liquid-reality.de
Re: Request for feedback: Refactoring of HTTP client authentication
Posted by Benson Margulies <bi...@gmail.com>.
Within my limited understanding this all seems fine to me.
On Wed, Dec 22, 2010 at 2:39 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I have now refactored the authentication of the http transport so the basic
> auth is now supported by DefaultBasicAuthSupplier. Spnego is now also
> supported using a SpnegoAuthSupplier.
>
> As I have changed some of the behaviour I would like to get some feedback
> before committing this.
> Please also see:
> https://issues.apache.org/jira/browse/CXF-3216
>
> Basic, Digest and Spnego / Kerberos auth can now be configured by simply
> setting the AuthType in the AuthorizationPolicy. The HttpConduit then
> creates a HttpAuthSupplier on the fly if none is configured explicitly.
> Still an AuthoriationPolicy on the message overrides the AuthorizationPolicy
> on the Conduit.
>
> I have also added a system test for DigestAuthSupplier as I changed the code
> and wanted to make sure it really works against a jetty insstance.
>
> There are some possible compatibility issues with my patch:
>
> * The first thing is that the HttpAuthSupplier is cached so it is
> created only once. If you later change the Authtype the supplier
> will stay the same. This can be solved by deleting the
> authSupplier so it is recreated.
> * The HttpAuthsupplier now overrides the AuthorizationPolicy on the
> message. Before the AuthorizationPolicy on the message would
> override the AuthSupplier. I don?t think anyone really would use this
> * If the message content is to be cached is now only determined by
> calling the requiresRequestCaching method on the authsupplier.
> Before the authSupplier was also asked for
> premptiveAuthentication. If this did not return null the message
> was also cached. I think this is not necessary as the authsupplier
> can still decide if caching is needed.
> * Currently you can set authType and authorization on the
> authorizationPolicy. This is then used to directly create the
> authorization header. This is used by the old spnego interceptor I
> added recently. I removed this feature as it is only really usable
> in an interceptor and it can be done better by creating a custom
> authSupplier
>
> Additionally I would like to remove the feature of setting an
> AuthorizationPolicy on the message. This would allow us to make the
> authsuppliers independent of conduit and message in the future.
>
> I also would like to introduce an authSupplier for proxy auth and handling
> of 407 responses so we can support multi phase authentications with a proxy.
>
> --
> ----
> http://www.liquid-reality.de
>
>
Re: Request for feedback: Refactoring of HTTP client authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Thu, Dec 23, 2010 at 3:41 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> I like it. Looks fine by me. The only "concern" I have is with:
>
> > Additionally I would like to remove the feature of setting an
> > AuthorizationPolicy on the message. This would allow us to make the
> > authsuppliers independent of conduit and message in the future.
>
> as that would likely break a bunch of things. For one, how do you plan
> on
> having the JAX-WS username/password properties? Currently, we map those
> directly onto and AuthorizationPolicy object on the message. Thus, that
> interaction would need to change as well.
>
>
Having an AuthorizationPolicy encapsulating the auth info such as name &
password seems ok to me.
I would not be surprised if removing it broke a number of JAX-RS
applications doing some custom authentication.
The CXF JAASLoginInterceptor also relies on it
cheers, Sergey
> Dan
>
>
>
>
>
> On Wednesday 22 December 2010 2:39:16 pm Christian Schneider wrote:
> > I have now refactored the authentication of the http transport so the
> > basic auth is now supported by DefaultBasicAuthSupplier. Spnego is now
> > also supported using a SpnegoAuthSupplier.
> >
> > As I have changed some of the behaviour I would like to get some
> > feedback before committing this.
> > Please also see:
> > https://issues.apache.org/jira/browse/CXF-3216
> >
> > Basic, Digest and Spnego / Kerberos auth can now be configured by simply
> > setting the AuthType in the AuthorizationPolicy. The HttpConduit then
> > creates a HttpAuthSupplier on the fly if none is configured explicitly.
> > Still an AuthoriationPolicy on the message overrides the
> > AuthorizationPolicy on the Conduit.
> >
> > I have also added a system test for DigestAuthSupplier as I changed the
> > code and wanted to make sure it really works against a jetty insstance.
> >
> > There are some possible compatibility issues with my patch:
> >
> > * The first thing is that the HttpAuthSupplier is cached so it is
> > created only once. If you later change the Authtype the supplier
> > will stay the same. This can be solved by deleting the
> > authSupplier so it is recreated.
> > * The HttpAuthsupplier now overrides the AuthorizationPolicy on the
> > message. Before the AuthorizationPolicy on the message would
> > override the AuthSupplier. I don?t think anyone really would use
> this
> > * If the message content is to be cached is now only determined by
> > calling the requiresRequestCaching method on the authsupplier.
> > Before the authSupplier was also asked for
> > premptiveAuthentication. If this did not return null the message
> > was also cached. I think this is not necessary as the authsupplier
> > can still decide if caching is needed.
> > * Currently you can set authType and authorization on the
> > authorizationPolicy. This is then used to directly create the
> > authorization header. This is used by the old spnego interceptor I
> > added recently. I removed this feature as it is only really usable
> > in an interceptor and it can be done better by creating a custom
> > authSupplier
> >
> > Additionally I would like to remove the feature of setting an
> > AuthorizationPolicy on the message. This would allow us to make the
> > authsuppliers independent of conduit and message in the future.
> >
> > I also would like to introduce an authSupplier for proxy auth and
> > handling of 407 responses so we can support multi phase authentications
> > with a proxy.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: Request for feedback: Refactoring of HTTP client authentication
Posted by Christian Schneider <ch...@die-schneider.net>.
Ok .. I guess it is better to not mess with this feature. I will shortly
prepare another patch to
remove the dependency to HttpConduit from the HttpAuthSupplier. Instead
I will add AuthorizationPolicy.
So the interface is also usable for the proxy auth. It already seems to
work quite well for me.
I will post some more details in a separate thread.
Christian
Am 23.12.2010 04:41, schrieb Daniel Kulp:
> I like it. Looks fine by me. The only "concern" I have is with:
>
>> Additionally I would like to remove the feature of setting an
>> AuthorizationPolicy on the message. This would allow us to make the
>> authsuppliers independent of conduit and message in the future.
> as that would likely break a bunch of things. For one, how do you plan on
> having the JAX-WS username/password properties? Currently, we map those
> directly onto and AuthorizationPolicy object on the message. Thus, that
> interaction would need to change as well.
>
> Dan
>
>
--
----
http://www.liquid-reality.de
Re: Request for feedback: Refactoring of HTTP client authentication
Posted by Daniel Kulp <dk...@apache.org>.
I like it. Looks fine by me. The only "concern" I have is with:
> Additionally I would like to remove the feature of setting an
> AuthorizationPolicy on the message. This would allow us to make the
> authsuppliers independent of conduit and message in the future.
as that would likely break a bunch of things. For one, how do you plan on
having the JAX-WS username/password properties? Currently, we map those
directly onto and AuthorizationPolicy object on the message. Thus, that
interaction would need to change as well.
Dan
On Wednesday 22 December 2010 2:39:16 pm Christian Schneider wrote:
> I have now refactored the authentication of the http transport so the
> basic auth is now supported by DefaultBasicAuthSupplier. Spnego is now
> also supported using a SpnegoAuthSupplier.
>
> As I have changed some of the behaviour I would like to get some
> feedback before committing this.
> Please also see:
> https://issues.apache.org/jira/browse/CXF-3216
>
> Basic, Digest and Spnego / Kerberos auth can now be configured by simply
> setting the AuthType in the AuthorizationPolicy. The HttpConduit then
> creates a HttpAuthSupplier on the fly if none is configured explicitly.
> Still an AuthoriationPolicy on the message overrides the
> AuthorizationPolicy on the Conduit.
>
> I have also added a system test for DigestAuthSupplier as I changed the
> code and wanted to make sure it really works against a jetty insstance.
>
> There are some possible compatibility issues with my patch:
>
> * The first thing is that the HttpAuthSupplier is cached so it is
> created only once. If you later change the Authtype the supplier
> will stay the same. This can be solved by deleting the
> authSupplier so it is recreated.
> * The HttpAuthsupplier now overrides the AuthorizationPolicy on the
> message. Before the AuthorizationPolicy on the message would
> override the AuthSupplier. I don?t think anyone really would use this
> * If the message content is to be cached is now only determined by
> calling the requiresRequestCaching method on the authsupplier.
> Before the authSupplier was also asked for
> premptiveAuthentication. If this did not return null the message
> was also cached. I think this is not necessary as the authsupplier
> can still decide if caching is needed.
> * Currently you can set authType and authorization on the
> authorizationPolicy. This is then used to directly create the
> authorization header. This is used by the old spnego interceptor I
> added recently. I removed this feature as it is only really usable
> in an interceptor and it can be done better by creating a custom
> authSupplier
>
> Additionally I would like to remove the feature of setting an
> AuthorizationPolicy on the message. This would allow us to make the
> authsuppliers independent of conduit and message in the future.
>
> I also would like to introduce an authSupplier for proxy auth and
> handling of 407 responses so we can support multi phase authentications
> with a proxy.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog