cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Request for feedback: Refactoring of HTTP client authentication
Date Thu, 23 Dec 2010 09:50:13 GMT
Hi

On Thu, Dec 23, 2010 at 3:41 AM, Daniel Kulp <dkulp@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
>

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