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.
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. 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.
-Fred On Jun 20, 2007, at 2:21 PM, Dan Diephouse wrote:
- WS-SX (Trust, SecureConversation, SecurityPolicy)
