cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: WS-SX
Date Tue, 25 Sep 2007 14:38:46 GMT
Sergey Beryozkin wrote:
> -----Original Message-----
> From: Sergey Beryozkin [] 
> Sent: 24 September 2007 21:31
> To:
> Subject: RE: WS-SX
> I think we're over-blowing the problem a bit. Lets not get sidetracked into 
> hypothetical discussions on how dangerous it is to put a private stuff into
> policies. Rather lets come up with a set of practical guidelines on when to
> use policies and features.
> Another thing I'd like to avoid is to have some religious debate leading
> nowhere. 
I really don't believe this is hypothetical or religious at all.
> Dan, you said you wanted to support WS-SecurityPolicy because it was so
> important for the enterprise. Now you're also saying that using features is
> so much better from an API perspective.
> I personally don't understand what is your position. I'm just confused. Can
> you please clarify?
Imagine I'm writing a GUI for CXF which configures the security for my 
services. As a CXF integrator, I don't want to have to generate policies 
to be able to configure a service. Features are much nicer to use. "new 
> Do you want support WS-SecurityPolicy by using WS-Security feature ? I don't
> think it makes any sense but I'd you to explain please.
I would like to be able to configure CXF specific configuration items 
(like key info) via a feature. Policies can then be attached.

I see policies and configuration of the other bits as two seperate 
processes. For instance, you may have a policy which you apply to all 
your services. But the key information may differ on each one.
> Can you explain please what you mean by saying it's so much harder to set up
> a service using a policy ? 
See above.
> I'd also like to suggest you to think of the following :
> * how can one satisfy a user's desire to attach capabilities to endpoints,
> operations, and bindings using features
Yeah, thats what Policy is for. Are you suggesting that users are going 
to have different key information for different operations? I can 
certainly see bindings/endpoints - and you can apply features at that level.
> * how can a client to avoid doing duplications like enabling MTOM on the
> client side when using features
I don't understand this question - if the client encounters an MTOM 
policy expression, it can just enable it. No feature needed.
> * how can a client perform intersection of capabilities using features
Eh? I'm not suggesting we rip out policy all together.

Speaking of the client: are you suggesting the client has to take a 
policy from a service, add in a bunch of extra expressions for key info 
and the like, and then deploy? Thats a hell of a lot of work. Thats what 
features are for: to supply configuration which is orthogonal to Policy.
> Or yes, one more thing. 
> How can one express 'or' combination using features, that is how one can do
> multiple alternatives, something one can easily do with policies :
> <Policy>
>   <All>
>   </All>
>   <All>
>   </All>
> </Policy>
> Alternatives are targeted at a consumer. Multiple consumers can choose their
> own alternatives and a provider will ensure it supports all the consumers.
> Consumers may also have their policies on which case they'll do the
> intersection. 
> This clearly shows that WS-Policy is not about configuration only. Looking
> at a WS-Policy language as the configuration option only is not correct. 
> I don't want push the message that using policies is the only true way to
> go. I'd just like us to agree on a policy (:-)) when polices should be
> applied.
Who's looking at WS-Pol as a configuration option only here? I didn't 
think anyone was.

So to summarize: we should use features for information which is not 
useful for the client and for stuff which should not be public beyond 
the local service. Because:
1. It makes API configuration of the service easier. No need to generate 
policy documents by hand.
2. Security considerations - Policy files are not easily tracked and 
will leak IMO
3. Configuration readability - WS-SecPol files are quite verbose/sticky. 
As Fred said: "Im less inclined to use WS-SecurityPolicy as a 
configuration mechanism, at least exclusively so.  It's not really 
designed to be human-readable, despite the fact that it's written in 
XML, and XML is supposed to be human-readable, etc etc."
4. Separation of concerns: Policy and configuration are two separate 
processes, often done at different stages. They also have different 
levels of reusability.

I'm not saying we couldn't also support policy expressions for 
configuration, but I think the use case for it is limited.  Again, as 
Fred said: "I agree that in some small percentage of cases, we need to 
support configuration of WS-SecurityPolicy directly, and at a low level, 
but these cases fall below the 20% bar, and can certainly be exposed 
through low-level config."

Of the above items, I will admit that 3/4 are potentially overcomeable 
but I would rank #1 & #2 as very important issues which kill the idea of 
configuring everything in Policy for me. We could also potentially use a 
feature to generate policy, but that would be a PITA IMO. It'd probably 
just be easier to interact with the WS-SX engine directly.

- Dan

Dan Diephouse
MuleSource |

View raw message