Hi On Thu, Dec 23, 2010 at 3:41 AM, Daniel Kulp <[email protected]> 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 > [email protected] > http://dankulp.com/blog >
