RE: Using attributes to mark RefProp's and RefParam's

Dims,

Can you give me an example of a SOAP header that you would not sign? The 
security
considerations section recommends signing all relevant headers. 

Keep in mind that any header not signed is subject to tampering. Any 
message that travels through
an intermediary is subject to header insertion (and deletion) attacks. 
Hence, a service that receives
messages should be highly suspect of any headers, regardless of type, that 
are not signed. It may even
implement a policy that precludes processing of any header that is not 
signed by a trusted source
(e.g. the sender (which has presumably been authenticated and authorized) 
and/or a trusted 
intermediary).

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



"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> 
Sent by: public-ws-addressing-request@w3.org
11/24/2004 07:52 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
<public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
Subject
RE: Using attributes to mark RefProp's and RefParam's







Ok. Then here's one scenario. I'd like my security proxy/intermediary to
check if all ReferenceParameters are signed and throw faults for the
rest and I don't want to keep adding new Qnames for every service that
gets added to the system.

-- dims

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Wednesday, November 24, 2004 6:45 PM
To: Srinivas, Davanum M
Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
Subject: RE: Using attributes to mark RefProp's and RefParam's

Technically viable? Yes.

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

"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> wrote on 11/24/2004
06:25:39 PM:

> So technically this is a viable solution ("we don't lose the ability 
> to leverage the SOAP processing model") right? If yes, I will write up

> some scenario for using it (intermediary/management/proxy type of 
> scenario)
> 
> Thanks,
> dims
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Christopher 
> B Ferris
> Sent: Wednesday, November 24, 2004 5:54 PM
> To: Srinivas, Davanum M
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: RE: Using attributes to mark RefProp's and RefParam's
> 
> 
> I'm still unclear as to why you think it necessary. If an endpoint 
> publishes an EPR with ref props and/or params, one assumes that it is 
> doing so full in the knowledge as to what it intends to do with these 
> as SOAP headers.
> The one thing that distinguishes them in the context of an EPR is that

> ref props are used in determinging EPR equivalence (e.g. that the two 
> equivalent EPRs have the same metadata (WSDL, schema, policy, etc.) 
> The intent of defining EPR equivalence is specifically so that the 
> sending node can know which policies it can expect will be applied (or

> which to apply).
> 
> 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
> 
> public-ws-addressing-request@w3.org wrote on 11/24/2004 05:21:17 PM:
> 
> > Is this a hot potato? :) no replies so far :)
> > 
> > From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > Srinivas, Davanum M
> > Sent: Wednesday, November 24, 2004 12:56 PM
> > To: public-ws-addressing@w3.org
> > Subject: Using attributes to mark RefProp's and RefParam's
> 
> > Team,
> > Me and Igor were chatting about how to mark RefProp's and RefParam's

> > on
> the way back AND still not
> > "lose the ability to leverage the SOAP processing model", here's the
> outcome?..Comments?
> > Suppose we have an EPR which says this: 
> > <wsa:EndpointReference>
> >    <wsa:Address>
> >         http://www.example.com/services/someService
> >    </wsa:Address>
> >    <wsa:ReferenceProperties>
> >         <tns:resourceID>DataChunk42</tns:resourceID>
> >    </wsa:ReferenceProperties>
> >    <wsa:ReferenceParameters>
> >         <tns:expires>32000</tns:expires>
> >    </wsa:ReferenceParameters>
> > </wsa:EndpointReference>
> > Can we have it come back as this? 
> > <SOAP-ENV:Envelope>
> >      <SOAP-ENV:Header>
> >          <wsa:MessageID>msgid:1234567902282223</wsa:MessageID>
> >
<wsa:To>http://www.example.com/services/someService</wsa:To>
> >          <wsa:Action>http://www.example.com/someAction</wsa:Action>
> > 
> > <wsa:From>http://www.example.com/clients/someClient</wsa:From>
> > 
> <wsa:ReplyTo><wsa:Address>http://www.example.com/clients/someOtherClie
> nt
> </wsa:
> > Address></wsa:ReplyTo>
> > 
> <wsa:FaultTo><wsa:Address>http://www.example.com/clients/yetAnotherCli
> en
> t</wsa:
> > Address></wsa:FaultTo>
> >          <tns:resourceID
> wsa:type="property">DataChunk42</tns:resourceID>
> >          <tns:expires wsa:type="parameter">32000</tns:expires>
> >      </SOAP-ENV:Header>
> >      <SOAP-ENV:Body>
> >         ...
> >      </SOAP-ENV:Body>
> > </SOAP-ENV:Envelope>
> > Davanum Srinivas
> > Computer Associates
> > Senior Architect, Web Services Group
> > Tel: +1 508 628 8251
> > davanum.srinivas@ca.com
> > http://ws.apache.org/~dims/
> > Davanum Srinivas
> > Computer Associates
> > Senior Architect, Web Services Group
> > Tel: +1 508 628 8251
> > davanum.srinivas@ca.com
> > http://ws.apache.org/~dims/
> 
> 
>

Received on Thursday, 25 November 2004 02:05:49 UTC