RE: [ws-sx] Issue 48: Proposal

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:] 
Sent: Wednesday, March 22, 2006 5:51 
AM
To: Tony Gullotta; 
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:] 
Sent: 15 March 2006 
  20:24
To: 
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)