You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <se...@iona.com> on 2007/09/24 15:33:43 UTC
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. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
"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 :
http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
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 [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> 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 [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> 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
> http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> 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
Re: Policies and features (Was : WS-SX)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Eric
yes, this is exactly how I see it myself. IMHO it makes sense.
As I said earlier this is just a guideline which I'd like us to come up with. At least users will see that we ourselves know when to use which approach, which will be better than just us saying you can configure the same thing using 3 different appproaches, choose yourself whichever approach you like.
More comments in other emails in this thread...
Thanks, Sergey
----- Original Message -----
From: "Johnson, Eric" <Er...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Monday, September 24, 2007 3:22 PM
Subject: RE: Policies and features (Was : WS-SX)
Pardon the real simplistic black/whiteness of this comment, but it is
directed toward figuring out the message to a user trying to sort out
which of the myriad configuration mechanisms to use....
So what you are saying, in general, is:
* Use policies when you want a service provider to advertise
requirements for interaction to a consumer. For example, I use RM and
require strong encryption.
* Use features to configure stuff that is local to a running process.
For example, use this persistent data store and this security key store.
For things like credentials and other private information the mechanism
gets more complicated, but for the user who is trying to figure out how
to set up a CXF based application the above rules are good.
Or am I missing something?
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Monday, September 24, 2007 9:34 AM
To: cxf-dev@incubator.apache.org
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. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
"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 :
http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
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 [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> 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 [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> 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
> http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> 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
RE: Policies and features (Was : WS-SX)
Posted by "Johnson, Eric" <Er...@iona.com>.
Pardon the real simplistic black/whiteness of this comment, but it is
directed toward figuring out the message to a user trying to sort out
which of the myriad configuration mechanisms to use....
So what you are saying, in general, is:
* Use policies when you want a service provider to advertise
requirements for interaction to a consumer. For example, I use RM and
require strong encryption.
* Use features to configure stuff that is local to a running process.
For example, use this persistent data store and this security key store.
For things like credentials and other private information the mechanism
gets more complicated, but for the user who is trying to figure out how
to set up a CXF based application the above rules are good.
Or am I missing something?
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Monday, September 24, 2007 9:34 AM
To: cxf-dev@incubator.apache.org
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. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
"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 :
http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
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 [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> 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 [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> 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
> http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> 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
Re: Policies and features (Was : WS-SX)
Posted by Sergey Beryozkin <se...@iona.com>.
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 'private=true'.
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" <eo...@iona.com>
To: <cx...@incubator.apache.org>
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
destination).
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.
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 24 September 2007 14:34
> To: cxf-dev@incubator.apache.org
> 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. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
> "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 :
> http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
>
> 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 [mailto:sergey.beryozkin@iona.com]
> > Sent: 23 September 2007 13:25
> > To: cxf-dev@incubator.apache.org
> > 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 [mailto:dan.diephouse@mulesource.com]
> > Sent: 22 September 2007 21:38
> > To: cxf-dev@incubator.apache.org
> > 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
> > http://mulesource.com | http://netzooid.com/blog
> >
> > ----------------------------
> > 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
Re: Policies and features (Was : WS-SX)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Fred
Only true security expert can express this concern :-)
I agree that putting a private stuff inside a public policy may not be desirable. As I said, I'm not trying to suggest that
"private stuff in public policies" is the only true way to go. I just feel it might be handy sometimes to be able to do so. We can put the private stuff into features. I'm not certain it will guarantee that no leakage will occur though :-) though it will be user's responsibility to keep that private info safe which is better for runtime :-)
Cheers, Sergey
----- Original Message -----
From: "Fred Dushin" <fr...@dushin.net>
To: <cx...@incubator.apache.org>
Sent: Monday, September 24, 2007 4:35 PM
Subject: Re: Policies and features (Was : WS-SX)
> Another is information "leakage". I am uncomfortable with putting
> sensitive security information in a service contract (such as a
> private key password), and just trusting the runtime to not publish
> it. How would an auditor be assured this information is not disclosed?
>
> -Fred
>
> On Sep 24, 2007, at 10:43 AM, Glynn, Eoghan wrote:
>
>> 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.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Policies and features (Was : WS-SX)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 24 September 2007 16:35
> To: cxf-dev@incubator.apache.org
> Subject: Re: Policies and features (Was : WS-SX)
>
> Another is information "leakage". I am uncomfortable with
> putting sensitive security information in a service contract
> (such as a private key password), and just trusting the
> runtime to not publish it. How would an auditor be assured
> this information is not disclosed?
Yep, the possibility of the WSDL "sanitization" being over-looked is one
of the things I was thinking about when I mentioned this extra step in
the deployment work-flow being an issue.
One approach to ensuring the sanitization always occurs would be only
publish WSDL to secure clients via the dynamic route (i.e. via a HTTP
"GET ...?wsdl" as opposed to a static copy of the WSDL file). Then the
pre-processing of the WSDL could be plugged into the WSDL QueryHandler
logic.
It would be clunky, but at least less error-prone than relying on the
deployer to manually run a pre-processor over the WSDL before
provisioning a static copy to the client.
Cheers,
Eoghan
> -Fred
>
> On Sep 24, 2007, at 10:43 AM, Glynn, Eoghan wrote:
>
> > 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.
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Policies and features (Was : WS-SX)
Posted by Fred Dushin <fr...@dushin.net>.
Another is information "leakage". I am uncomfortable with putting
sensitive security information in a service contract (such as a
private key password), and just trusting the runtime to not publish
it. How would an auditor be assured this information is not disclosed?
-Fred
On Sep 24, 2007, at 10:43 AM, Glynn, Eoghan wrote:
> 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.
RE: Policies and features (Was : WS-SX)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
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
destination).
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.
Cheers,
Eoghan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 24 September 2007 14:34
> To: cxf-dev@incubator.apache.org
> 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. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
> "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 :
> http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3
>
> 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 [mailto:sergey.beryozkin@iona.com]
> > Sent: 23 September 2007 13:25
> > To: cxf-dev@incubator.apache.org
> > 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 [mailto:dan.diephouse@mulesource.com]
> > Sent: 22 September 2007 21:38
> > To: cxf-dev@incubator.apache.org
> > 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
> > http://mulesource.com | http://netzooid.com/blog
> >
> > ----------------------------
> > 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