RE: [ws-rx] issue 115: clarifying question

From
Gilbert Pilz <>
Date
2006-04-25T03:25:46+00:00
ID
Thread
RE: [ws-rx] issue 115: clarifying question
Another problem with this is that it 
complicates the security processing. Any time I have an extension that 
"significantly" modifies the semantics of the underlying operation (pretty much the definition of why I would 
want to use "mustUnderstand" in the first 
place) there is an implicit 
security threat if someone is able to strip off the "mustUnderstand" flag (however it's represented). Under your model 
every "foo:ExtensionFlag" header would have to be included in a signature 
that binds the header to the actual thing that is being extended (body or other header) 
together. Under the proposed solution the "wsrm:mustUnderstand" 
attribute would be signed along with 
the thing it is extending.

 

- 
gp

  

  
  From: Christopher B Ferris 
  [mailto:] 
Sent: Monday, April 24, 2006 6:07 
  PM
To: Gilbert Pilz
Cc: wsrx
Subject: Re: 
  [ws-rx] issue 115: clarifying question

  

Gil, 

Actually, I had something more like this in 
  mind: 

<?xml version="1.0" 
  encoding="UTF-8"?>
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200604" 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
  
xmlns:foo="http://example.org/foo"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<S:Header>
 <foo:SecureRM 
  S:mustUnderstand="1"/>
 <wsa:MessageID>
  
  http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
 </wsa:MessageID>
 <wsa:To>http://example.com/serviceB/123</wsa:To>
  
   <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200604/CreateSequence</wsa:Action>
 <wsa:ReplyTo>
  
  <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
 </wsa:ReplyTo>
</S:Header>
<S:Body>
 <wsrm:CreateSequence>
  
   <wsrm:AcksTo>
     <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
  
   </wsrm:AcksTo>
  
   <wsse:SecurityTokenReference>
     ...
  
   </wsse:SecurityTokenReference>
 </wsrm:CreateSequence>
</S:Body>
</S:Envelope>

Cheers, 

Christopher Ferris
STSM, Software Group Standards 
  Strategy
email: 
blog: 
  http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 
  377 9295 

"Gilbert Pilz" 
  <> wrote on 04/24/2006 05:41:23 PM:

> 
  During the conference call of 4/20/2006 Chris asserted that you can 
> 
  use a SOAP header with a mustUnderstand attribute to flag the fact 
> 
  that some element in either another header or in the message body is
> 
  an extension that must be understood by the receiver. I'm not sure I
> 
  understood exactly what Chris thought this should look like. For 
> 
  example, imagine the following CreateSequence message. The extension
> 
  elements have been marked in bold. What is supposed to go in the 
> 
  <wsrm:Extension> header?
> 
> <?xml version="1.0" 
  encoding="UTF-8"?>
> <S:Envelope 
  xmlns:S="http://www.w3.org/2003/05/soap-envelope"
> 
  xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200604"
> 
  xmlns:wsa="http://www.w3.org/2005/08/addressing">
> 
   <S:Header>
>   <wsrm:Extension 
  S:mustUnderstand="1">
>     ????
>   
  </wsrm:Extension>
>   <wsa:MessageID>
>   
   http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
> 
    </wsa:MessageID>
>   
  <wsa:To>http://example.com/serviceB/123</wsa:To>
>   
    
  <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200604/CreateSequence
> 
  </wsa:Action>
>   <wsa:ReplyTo>
>   
   <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> 
    </wsa:ReplyTo>
>  </S:Header>
> 
   <S:Body>
>   <wsrm:CreateSequence>
>   
    <wsrm:AcksTo>
>       
  <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> 
      </wsrm:AcksTo>
>     
  <wsrm:SecurityComposition>
>       
  <wsrm:Identifier>
>         
  http://docs.oasis-open.org/ws-
> 
  rx/wsrmsp/200604/profile/http_auth/samenode
>       
  </wsrm:Identifier>
>     
  </wsrm:SecurityComposition>
>   
  </wsrm:CreateSequence>
>  </S:Body>
> 
  </S:Envelope>
> 
> I'm sure that most of us could all come 
  up with a reasonable design 
> to do what you suggest, but for the 
  purposes of further discussion 
> I'd like to know what design Chris had 
  in mind?
> 
> - gp