On 6/20/07, Fred Dushin <[EMAIL PROTECTED]> wrote:
I think we need to think long and hard about how WS-SecurityPolicy fits into the current WS-Security interceptor. As a start, I'd recommend we remove any WSS4J-isms in the exposed interfaces (programmatic and configuration), and instead focus on exposing these through JAX-WS features.
We can then focus on how WS-SecurityPolicy objects clash/complement
features defined statically in config.
Yeah. The current ws-security stuff is very basic and is in desperate need of an overall as we do the WS-SX stuff. We need to make sure the WSSecurityFeature API, SecurityPolicy and WS-SX stuff all align well, which is no trivial task. Or maybe it is - I honestly am not enough of a SecPol/SX expert to comment. Maybe we can start a wikipage and start capturing requirements/ideas. Before we do any more feature work, though, I think we need to get a
definition of jaxws:features at Bus scope, though I think there may be a slight semantic disconnect there. The beauty of defining things at Bus scope is that it can serve as a fallback/default mechanism for configuration that is not defined on a specific client or endpoint.
https://issues.apache.org/jira/browse/CXF-742 - I targeted this for 2.0.1 But the way the AbstractFeature stuff is defined, setting "features"
on an InterceptorProvider, when the InterceptorProvider is a Bus, is / additive/ on the ultimate list of interceptors -- it's not, in particular, a default fallback mechanism. (Please correct me if I've got that wrong) So I think a little more design work needs to go into that.
Are you thinking about a case where two features might add the same interceptors to an InterceptorProvider? Can you explain a little bit more the case where multiple features are adding the same interceptors to a Bus/Client/Server? Thanks, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
