RE: [ws-sx] Issue 48: Proposal

["Tony Gullotta" <tony.gullotta@soa.com>]

As I said in the call, I wouldn't design an endpoint this way myself so I'm only speaking to what we've been asked by customers for. I think in general the problem with the approach of separating endpoints based on security requirements is that its not typical that service providers think of security during design. I think more often they have ideas for grouping related functions they want to expose first. Then they try and figure out security after. Also, I think security requirements can change over time possibly for a given operation. I don't believe customers would want to disrupt their consumers and refactor their service endpoints every time a security change is required for a given operation. I think it would be preferable to only change the security policies around those operations and allow consumers to adapt to the policy changes.

 

I would suggest that as spec builders we shouldn't try to force service design too much. If a service provider wants different security around operations, I think that should be their call. We can suggest not to do that, but I don't think this spec should explicitly disallow it. We do allow different signatures and encryption blocks per message today so a consumer has to "join" all policies at the different subject scopes already. At what level they pick up the policies isn't going to change the resulting effective policy.

 

I will ping our field engineers to see if I can come up with a customer scenario or two.

 

Tony

---

From: Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: Wednesday, March 22, 2006 5:51 AM
To: Tony Gullotta; ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: RE: [ws-sx] Issue 48: Proposal

Tony,

I'm not sure how to think about this proposal. I tend to think of the operations exposed via a web service endpoint as sharing common characteristics, especially with respect to the fundamental security aspects of message exchange. I'm not quite sure how to think about an endpoint that exposes multiple operations that use a mixture of asymmetric and symmetric bindings. I think that such operations would be better separated into seperate endpoints, one of which used an asymmetric binding and another which used symmetric bindings.

Similarly, an endpoint that exposed multiple symmetric binding based operations that use a mixture of token types for the protection token seem better separated into multiple endpoints, one for each token type.

In both the above cases, when multiple endpoints are used all the operations of a given endpoint share security characteristics such as cryptographic and other algorithms, how client and server authentication happen, what correlation guarantees are present. I think having all operations of an endpoint share such characteristics is a good thing. And I'm concerned that there is more possibility for introducing weaknesses if different operations on the same endpoint have different fundamental security characteristics.

 

Essentially, I think I see this as a slippery slope where I'm not sure what length or what number of nasty spikes I'm going to impale myself on when I hit bottom.

 

Regards

 

Gudge

 

P.S. I apologise to both yourself and the TC as a whole for the tardiness of this response relative to both your original proposal and proximity to the call today.

 

 

---

From: Tony Gullotta [mailto:tony.gullotta@soa.com]
Sent: 15 March 2006 20:24
To: ws-sx@lists.oasis-open.org
Subject: [ws-sx] Issue 48: Proposal

I have listed a more specific proposal below. The proposal is based on the ws-securitypolicy spec version http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/16289/ws-securitypolicy-1.2-spec-ed-01-r04.pdf.

 

Section 7.4 lines 1529 - 1530 should be changed from:

 

This assertion MUST apply to [Endpoint Policy Subject].

 

to:

 

This assertion SHOULD apply to [Endpoint Policy Subject]. This assertion MAY apply to [Operation Policy Subject].

 

Section 7.5 lines 1606 - 1607 should be changed from:

 

This assertion MUST apply to [Endpoint Policy Subject].

 

to:

 

This assertion SHOULD apply to [Endpoint Policy Subject]. This assertion MAY apply to [Operation Policy Subject].

 

The following should be added after line 2201 in Appendix A:

 

A.2.2 Security Binding Assertions

 

SymmetricBindingAssertion            (8.4)

AsymmetricBindingAssertion          (8.5)