ws-sx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-sx] Issue 48: Proposal
- From: "Tony Gullotta" <tony.gullotta@soa.com>
- To: "Martin Gudgin" <mgudgin@microsoft.com>,<ws-sx@lists.oasis-open.org>
- Date: Wed, 22 Mar 2006 09:11:37 -0800
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
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.
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)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]