RE: Composibility problems with refps

I think that Gudge had the right answer to this form of hackery... only 
accept EPRs
that are signed by trusted partners.

As to the point of interface extending into the headers, the situation is 
no worse than 
for ws-* protocol headers... if someone does something that is in conflict 
with something
else, then it needs to be worked out. That simple. You cannot preclude 
stupidity or malice
either by legislation or specification.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295



"David Orchard" <dorchard@bea.com> 
11/22/2004 07:25 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
<public-ws-addressing@w3.org>
Subject
RE: Composibility problems with refps








> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Monday, November 22, 2004 4:07 PM
> To: David Orchard
> Cc: public-ws-addressing@w3.org
> Subject: RE: Composibility problems with refps
> 
> David,
> 
> That's a pretty far fetched example:-) Why would I choose to
"understand"
> <allYourAssetsAreBelongToUs/>?

I wouldn't want to preclude a bank from having an interface that deals
with account transfers.  SOAP gives a powerful extensibility model for
interfaces, and an account transfer is a possible example of a header
block.  Oh, is this the "make the example sound as ridiculous and
farfetched and silly as possible" argument style? 
> 
> And how is the example you give an example of duplicate user headers
> (whatever they are)? 

It's a duplicate user header because the service offers the
"SendAssetsToGrandCayman" interface as a soap header that clients can
invoke, which is also accidentally or intentionally invoked by the EPR.

> And what makes
> you say that duplicates would necessarily be a security hole? 

Because the hacker gets the minter of the EPR to put the "sendAssets"
header in the EPR.  According to the WS-A processing model, they can't
tell whether it is a legit header block or not, they just echo away.

> And how does
> a wrapper mitigate against any of this?

Because the EPR could contain the "sendAssetsToGrandCayman" RefP, but it
wouldn't be sent as a soap header block, and thus the functionality
wouldn't be invoked.

> 
> By your account, we shouldn't have a SOAP processing model at all
because
> some unscrupulous client
> could stick in a <sendMeAllYourAssets soap:mustUnderstand='true'/>
header
> block.

No, that's not the same, because the two sides agree upon the interface
and the client is allowed to send the "sendassets" header block.  I'm
just pointing out a case where there's a valid interface, the EPR minter
can get hacked, and the normal model of EPRs - even with securing the
EPR - doesn't prevent the wrong thing from happening. 

People can easily say "well don't get hacked internally" but that's
harder said than done.

Cheers,
Dave

<snip/>

Received on Tuesday, 23 November 2004 00:37:39 UTC