cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Policies and features (Was : WS-SX)
Date Mon, 24 Sep 2007 17:21:34 GMT
Hi Eoghan

I agree with your analysis. 
"public stuff in the policy, private stuff in the feature, merge at runtime" seems a better
approach in general as it
advocates the right seperation of concerns and avoids some edge cases (some private extensions
which could be understood by consumers using the same policy aware runtime and such can be
kept inside) one would have to deal with otherwise. It'll likely be more performant. 

I believe Metro deals with edge cases by marking truly private stuff by an attribute like

That said I feel we should let people to embedd the private stuff into policies too, possibly
with the exception for security policies (to make security people happy :-))...This might
help design tools to process such policies. I agree it can be a performance issue but at the
same time it's a once-only hit. 

When referring to "Publish the WSDL" task I mean the service provider exposing the service
contract to the consumer, either directly or indirectly by publishing it to some registry,
so it's a response to a dynamic HTTP "GET ...?wsdl" query in the former case. I was thinking
of WSDLPublisher, at a publish time, just removing the private stuff inside policy expressions
at a publication time only, possibly checking for 'private' attribute.

So I like what you suggested about the seperation, it's just that I feel it might be useful
in some cases to get "the private stuff inside policies" working too, but I wouldn't be concerned
about it now as long as we agree on the general principle : public stuff to consumers (and
runtime), private stuff to the  runtime only.

Cheers, Sergey

----- Original Message ----- 
From: "Glynn, Eoghan" <>
To: <>
Sent: Monday, September 24, 2007 3:43 PM
Subject: RE: Policies and features (Was : WS-SX)

Hi Sergey,

I agree with much of what you said, in particular that we need to be
clearer in our guidance to help users decide whether they should assert
a policy or apply an "equivalent" feature (the equivalence being fuzzy
at best).

Your suggested inclusion of private stuff in the policy assertions, to
be stripped out when the WSDL is published, is interesting.

In order for this to work, we'd need a well-defined concept of what it
means to "publish" the WSDL. As things stand, the client usually gets
hold of the WSDL in one of two ways, either as a local static copy of
the WSDL file or in response to a dynamic HTTP "GET ...?wsdl" query. 

So were you thinking of something like a pre-processor tool that would
be applied to the WSDL to sanitize it of anything unsuitable for the
client's consumption? Potential issues would include (1) the overhead of
an extra step in the deployment work-flow and (2) the incremental work
required for each policy type to make this tool aware of the distinction
between private and public child-elements.

I suppose one approach to #2 would be simply base it on the schema for
the policy type, e.g. any element not in the standard schema would be
considered "private".

However, there are certain potential extensions of the standard policies
that aren't strictly-speaking private and could be "interesting" to the
client, so we may not necessarily want to strip these out. 

For example, it may be useful for the client to know that the
ws-rm:reliableMessaging/deliveryAssurance in effect on the
destination-side is AtMostOnce, and use this knowledge to be more
aggressive in resending non-idempotent un-acknowledged messages (safe in
the knowledge that any duplicates would simply be discarded by the RM

Now one advantage of the alternative approach (public stuff in the
policy, private stuff in the feature, merge at runtime) is that this is
pretty close to what we have right now. We don't enforce the
distinction, but for certain policies/features it is possible to follow
that pattern.


> -----Original Message-----
> From: Sergey Beryozkin [] 
> Sent: 24 September 2007 14:34
> To:
> Subject: Policies and features (Was : WS-SX)
> Hi Eoghan
> I've created a new topic so that I don't interfere with the 
> original WS-SX topic...
> I'd like to step back for a second before answering to your 
> specific question.
> Lets say we have an ability to express the same 
> capability/requirement using several alternative mechanisms, 
> for ex, using a WS-Policy policy expression and a CXF 
> feature. We can probably agree that providing several options 
> is confusing to users and to those writing the documentation. 
> At the same time I don't think we can enforce the usage of a 
> single alternative. Hence we should have a good idea of when 
> to the WS-Policy expressions, when to use CXF features, when 
> to use both, and provide guidelines. 
> IMHO a general guideline is : if it's of public interest 
> (interest to consumers) then it's a policy. Otherwise it's a 
> feature. If policy-unaware consumers are targeted then both 
> alternatives might be used, as such consumers still have to 
> configure themselves. If it's a consumer which is being 
> configured then both alternatives are usable too but the 
> policy is better because more advanced WS-policy features can 
> be used when both a consumer and a provider are configured 
> with ws-policy.
> I think it was too strong to suggect a WS-Security feature 
> would be redundant/obsolete if WS-SecurityPolicy were 
> supported. I just don't see why would people use a CXF 
> feature if a corresponding WS-SecurityPolicy expression were 
> available. Only if we could have this feature usable in 
> scenarios when no WS-Security was involved (say when people 
> work with restful services and do XMLEncryption, etc) then I 
> can see why would people choose to use a feature. 
> When users are unhappy when seeing WS- appendix then let them 
> use features and not worry about policies (though it's worth 
> saying a WS-Policy language is not bound to WS-* services and 
> the frameworks defines the mechanism to attach policies to 
> arbitrary XML elements).
> If we were to use WS-SecurityPolicy then we'd need to decide 
> where the private stuff would go. As I said earlier two 
> options are possible. 
> One is to embedd the private stuff inside the policy itself 
> and strip it out at the publication time, works with 
> wsdl/java first developement, see for example :
> 1.
> "As is the case when you develop your service from WSDL, 
> private policy assertions are removed before the final WSDL 
> is published. "
> 2. Similar pattern is used in Apache Rampart :
> Alternative approach is to put the public stuff into a policy 
> and a private stuff into a feature and merge the info. 
> Possibly using the advanced CXF feature mechanism where a 
> policy assertion can be embedded into a feature, as in case 
> with RM assertions.
> So finally I'm getting to your question :
> >>Would the same logic apply to the reliableMessaging feature 
> versus the 
> >>RMAssertion?
> I believe we should advise users to use a reliableMessaging 
> feature only when it can add a private stuff (which is of no 
> interest to consumers of such polices) in addition to what a 
> public WS-RM policy can already express.
> Alternatively we can advise people to put a private stuff 
> inside a policy itself but we'd have to strip it off at the 
> publication time. In case of RM we may not even have to do it 
> as the private stuff won't be as sensitive as the private 
> security stuff and well-behaved RM consumers should ignore 
> unrecognized RM extensions.
> I think both options can be supported, but with guidelines 
> people would be less confused with a number of configuration 
> options we have. 
> Would you agree with what I said ?
> Thanks, Sergey
> Hi Sergey,
> A quick question on your observation that the WS-Security 
> feature would be redundant/obsolete if WS-SecurityPolicy were 
> supported.
> Would the same logic apply to the reliableMessaging feature 
> versus the RMAssertion?
> Obviously there are some differences in the RM case, in the sense that
> (a) an RMAssertion can be embedded in the reliableMessaging 
> feature, and
> (b) otherwise the primary purpose of the reliableMessaging 
> feature is to specify "non-private" behavior outside the 
> scope of the RMAssertion (e.g. the sequenceTerminationPolicy).
> But I'm wondering if your line of reasoning would extend to 
> embedding e.g. the sequenceTerminationPolicy as a custom 
> extension of the RMAssertion?
> Cheers,
> Eoghan 
> > -----Original Message-----
> > From: Sergey Beryozkin []
> > Sent: 23 September 2007 13:25
> > To:
> > Subject: RE: WS-SX
> > 
> > Hi
> > 
> >  
> > 
> > A couple of comments on WS-SecurityPolicy:
> > 
> >  
> > 
> > 1.       The core policy framework needs to be enhanced a bit 
> > to deal with
> > the normalization of nested polices which are abound in 
> > WS-SecurityPolicy policies,
> > 
> > to deal with the effective policy calculation when multiple 
> > Ws-SecurityPolicy polices are attached to multiple points 
> for a given 
> > policy subject like Endpoint, etc.
> > 
> > This is something I'd be willing to contribute to.
> > 
> > 2.       Supporting those policy assertions which map to what 
> > CXF security
> > runtime already supports would be a great start IMHO. This 
> includes an 
> > HTTPS-related assertion too.
> > 
> >  
> > 
> > A separate comment on a WS-Security feature. I strongly 
> believe that 
> > we need to revisit the guidelines on when to use WS-Policy 
> expressions 
> > as opposed to CXF features.
> > 
> > For ex, lets take WS-SecurityPolicy which we all agree is worth 
> > supporting.
> > WS-SecurityPolicy policy expressions are in themselves can do the 
> > configuration just fine.
> > 
> > But using policy expressions provides for much more than just 
> > statically configuring the runtime. They allow for a next 
> to unlimited 
> > set of enhancements be applied to the consumer of
> > 
> > services annotated with such polices. Hence when thinking on how a 
> > given capability or requirement should be  configured one should 
> > prefer using policy expressions when
> > 
> > such requirements can be of use to a client/consumer.   
> > 
> >  
> > 
> > If we take WS-SecurityPolicy then we can see its policy expressions 
> > are about expressing requirements to the consumers. 
> Configuration is a 
> > positive side-effect. One can attach such a WS-SecurityPolicy 
> > assertion either directly in a WSDL, or using an external 
> attachment 
> > mechanism supported by CXF. I believe Metro and Axis2 support both 
> > approaches.
> > Either way, the question arises where to put the private 
> stuff, like 
> > the key material location, passwords, and the like. One 
> approach is to 
> > put them inside the policy expression and strip them out at a WSDL 
> > publication time.
> > Another approach is to put the private stuff outside the policy 
> > expression but then merge the information from multiple sources. 
> > Either approach has its pros and cons. The latter approach, by the 
> > way, works perfectly well with Java-first style of service 
> > development, the runtime could smartly annotate the WSDL at a 
> > publication time, which is what Metro can do.
> > 
> >  
> > 
> > So lets have a look at a WS-Security feature. Basically I 
> believe that 
> > if we start supporting WS-SecurityPolicy then the 
> WS-Security feature 
> > becomes redundant/obsolete. If one uses WS-SecurityPolicy then one 
> > does not need to use WS-Security feature, and if one uses a 
> > WS-Security feature then there's no point in using 
> WS-SecurityPolicy. 
> > Supporting both WS-SecurityPolicy and WS-Security feature 
> will add to 
> > the confusion people already when choosing how to configure a given 
> > capability. Additionally, using policies one can annotate 
> the contract 
> > at a very fine-grained fashion, which is not possible when using 
> > features.
> > 
> >  
> > 
> > I still think something like WS-Security feature has its 
> > place. It can be used by users which just don't want to use 
> > WS-SecurityPolicy for whatever reasons and who are happy with 
> > being able to annotate a limited part of the contract. More 
> > realistically though one can probably use WS-Security feature 
> > to keep the private stuff like passwords but have everything 
> > else kept in the corresponding policy expression.  
> > 
> >  
> > 
> >  Cheers, Sergey
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> >   _____  
> > 
> > From: Dan Diephouse []
> > Sent: 22 September 2007 21:38
> > To:
> > Subject: WS-SX
> > 
> >  
> > 
> > One of the things on my wishlist for 2.1 is support for WS-SX 
> > - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its 
> > a very important feature for a lot of corporations because it 
> > enables much faster security and it also enables a range of 
> > security scenarios which weren't possible before. 
> > 
> > I know I've chatted with Fred a bit about this before, but 
> > I'd like to bring the discussion to the dev list for a while 
> > so we can a) figure out the scope of the work b) decide if we 
> > can do it for 2.1 and c) figure out who's going to do what. 
> > Regarding this last point, I will be very happy to 
> > particpate, but I'm not sure I can do the majority of the 
> > work. But I can certainly code some and help brainstorm.
> > 
> > At a high level I suppose there are several things we need to do:
> > 
> > 1. Build a WS-Trust service for token exchange. At the 
> > very least we
> > need to be able to create symmetric keys from the asymmetric 
> > public keys for WS-SecureConversation.
> > 2. WS-SecurityPolicy
> > 
> > 1. First we need to start using JAXB catalog files. These 
> > files allow
> > JAXB to use classes which have already been generated when 
> > doing xsd2java.
> > In other words, our ws-security module can generate the 
> > security policy beans and reference the beans in the policy 
> > module. Whereas right now, the policy beans would be 
> > regenerated by JAXB. This requires an upgrade to JAXB
> > 2.1 and also it requires use of the official/Mojo JAXB plugin 
> > instead of our own. Our own plugin is architected in such a 
> > way that adding this feature isn't really possible without a 
> > rewrite, which seems like a waste of time.
> > 2. Which, if not all, policy assertions do we need to support?
> > 
> > 3. WS-SecureConversation service and interceptors
> > 4. WS-Security feature for configuration (I heard through 
> > the grapevine
> > someone may have started on this. Would be interested to see 
> > what has been done - I really like the way Spring-WS does 
> > WS-Security configuration so it may be interesting to look 
> into that)
> > 
> > So with that - anyone else looked into this in more detail? 
> > Anyone want to help pick up this feature for 2.1?
> > 
> > Cheers,
> > - Dan
> > 
> > 
> > 
> > --
> > Dan Diephouse
> > MuleSource
> > |
> > 
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered 
> > Number: 171387 Registered Address: The IONA Building, 
> > Shelbourne Road, Dublin 4, Ireland
> > 
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, 
> Dublin 4, Ireland
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, 
> Dublin 4, Ireland

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

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