Re: One-way MEP with security

With respect, I think this analysis is unintentionally glossing over an 
important point in the 2nd part where it discusses implementation within 
the SOAP envelope.  The purpose of a SOAP binding is to deliver a message 
over a single SOAP "hop", and an MEP needs to describe the 
responsibilities of the bindings in which the MEP is implemented.  I 
believe that what David sets out is a valid example of intermediary 
processing, but he doesn't seem to settle the important question of 
whether the scenario is supportable without a SOAP intermediary.  I think 
it's not.  The responsibility of a SOAP binding is clearly to deliver the 
SOAP envelope intact from sender to receiver.  The binding itself MUST NOT 
rewrite the envelope, though it can alter other properties.

As I say, I think you can use SOAP intermediaries, but this is not an 
entirely transparent solution.  To spec this out, we'd have to identify 
the roles, if any, played by that intermediary.  If the SOAP security 
header in question is targeted to a role, then the intermediary should 
play that role, and there should be a specification for the corresponding 
header that specifies the behavior of the intermediary in rewriting 
(removing and reinserting) that header.  If there is no processing of SOAP 
headers, then the intermediary is an 'active one'.  It still has 
responsibilities for knowing what roles it's playing, implementing relay 
rules, etc. 

My point is that the difference between a binding-based and an 
intermediary-based solution is sometimes observable from the outside.  A 
binding >never< rewrites the envelope.  An intermediary is a pretty 
heavyweight abstraction.  While you can do it either way, I think my 
preferred approach to this scenario would usually be to model it as the 
sending of multiple, parallel SOAP messages, each with a different 
envelope, I.e. to account for the different signatures.  Indeed, that's 
>exactly, what will be happening as outbound traffic from David's 
intermediary.  I'm not 100% sure what's gained by moving that complexity 
one-node downstream.  It's always true that you can build SOAP gateway 
applications, and can use a one/way or request response to send any 
request to a gateway, which will do arbitrary processing and transmit 
arbitrary SOAP messages as side effects of that processing.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








David Hull <dmh@tibco.com>
Sent by: xml-dist-app-request@w3.org
10/26/2006 09:58 AM
 
        To:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        One-way MEP with security



I have an action to propose text explaining possible subtle interactions
between the one-way MEP and, say, a SOAP security mechanism which
encodes a message to a receiver with that receiver's public key, in
other words, one which, given a single sent SOAP message, produces a
different SOAP message for each recipient.

On further reflection, I'm not convinced that anything subtle is going on.

First, consider a scenario where security is handled outside SOAP.  I
believe that XMPP can provide such an example.  In this case:

    * The sender sends a plaintext SOAP message
    * The transport encrypts that message, producing a different message
      on the wire for each recipient.
    * For each receiver, the transport decrypts that receiver's copy
    * Each receiver receives a plaintext SOAP message.

Clearly, this is an example of the one-way MEP, in which there happens
to be more than one receiver.

Now consider a scenario where security is handled within SOAP.

    * The sender sends a plaintext SOAP message to an intermediary
    * The intermediary encrypts that message, producing a different SOAP
      message for each recipient, which it then sends out.
    * For each receiver, an intermediary receives an encrypted SOAP
      message and produces a plaintext SOAP message, which it sends to
      the receiver
    * Each receiver receives a plaintext SOAP message.

Clearly, this is an example of the one-way MEP, in which there happens
to be more than one receiver.

As it happens, it also involves several other examples of the one-way
MEP, each with a single receiver.

The one-way MEP is playing a crucial role here.  It provides a standard
way to assert that each receiver receives the same plaintext message,
whatever happens in the middle.  Put another way, it provides a standard
way to assert that the overall behavior of the two systems is the same. 
You can use the underlying transport's security if it's available.  If
it's not, or if you otherwise choose not to, you can handle security
end-to-end using SOAP.

As far as I can tell, this is not a subtle interaction between security
and the one-way MEP.  It is simply layering.

Received on Monday, 30 October 2006 04:43:54 UTC