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

On Nov 25, 2004, at 11:11 AM, Christopher B Ferris wrote:
>
> Ok, let's say I have a gateway that serves as the external facing 
> endpoint
> for all of my internal services, which are hidden behind a firewall.
> I could expose an EPR that has the wsa:Address URI of my external 
> gateway
> and include ref prop(s) that are targetted at the soap:role of
> http://example.org/gateway which is the role of my Gateway. It knows 
> only
> to look for an element <gw:RouteTo> or something like that, of type
> xs:anyURI with a
> soap:MustUnderstand='true', and forwards the message to that URI, which
> could
> be an HTTP URI or possibly a URI for a WebSphereMQ queue from which the
> service endpoint will dequeue messages to be processed (asynchronously,
> of course! It's the only way babe... :-)

A few questions:

(i) Is the gateway a SOAP intermediary or the ultimate recipient ?
(ii) Why can't the gateway look for a wsa:To/gw:RouteTo instead ?

>  If the ref props/params are
> wrapped,
> then somehow the soap:role and soap:mustUnderstand of the ref 
> prop/param
> will need to be
> propogated to that wrapper element or else this use of ref props/params
> doesn't work.
>
Why doesn't it work ? The gateway can look for wsa:To/gw:RouteTo and if 
it doesn't find one it can return a wsa:DestinationUnreachable fault. 
In essence the gateway is acting in a routing capacity and is using the 
message addressing properties to do that. If we wrap the destination 
EPR then the SOAP processing rules for wsa:To can be written to support 
this kind of usage - e.g. target wsa:To to 'next', make it 
mustUnderstand='true' (mebbe), reinsert after processing, chuck a 
wsa:DestinationUnreachable if the header doesn't contain sufficient 
information to route to the next hop, etc.

If ref props params are being used for addressing and routing rather 
than for invoking arbitrary ws-* functionality then it makes sense (to 
me anyhow) to have wsa:To be an EPR with clear processing semantics.

Marc.

> As for your point: "Nobody else does it.", I don't know what you mean 
> by
> this.
> Do you mean that there has, to date, been relatively little 
> exploitation
> of
> soap:role/actor? If so, I agree but I don't think that is an excuse to
> preclude its
> use in the design of WS-Addressing.
>
> As for the point: "It becomes impossible to write generic "process
> addressing information" (e.g., WS management infrastructures) without
> closely coupling the layers on a *per-operation* basis.". I don't buy
> that.
> Just because the ref props/params can be anything, doesn't mean that 
> there
> won't be a set of well-defined Qnames that can be baked into some
> infrastructure
> like WebSphere. The beauty of ws-addressing is that it allows for the
> minter
> of the EPR to be free to implement as it chooses and it doesn't impact 
> the
> implementation choices of the recipient of that EPR. It just works.
>
> As to the point: "It goes against the philosophy of composable 
> headers.".
> Please
> explain why it is you think that.
>
>>
>> I think "we" have made our case that there are real security, and
>> coupling, concerns by doing this, and that it goes against the grain 
>> of
>> everyting else in ws-xxx-land being self-identifying.  I think now 
>> "you"
>> should need to answer the question above.
>
> I've given a real-world use case above for leveraging the SOAP 
> processing
> model.
> I could certainly think of others.
>
>>
>> The problem with Dim's suggestion to add an attribute is that it
>> now makes it impossible for anyone to sign a refprop/param directly
>> (you have to use an XPath transform or something similar), since
>> the content changes during the promotion.
>>
>>> I don't understand that scenario. A given endpoint X expects certain
>>> SOAP headers to be in a message.
>>
>> This requires that endpoint X not have any optional headers, else you
>> are subject to the insertion attacks discussed earlier.  I do not 
>> think
>> it is reasonable to prohibit optional data, and the security cost of
>> allowing it seems too high.
>>
>>    /r$
>>
>> -- 
>> Rich Salz                  Chief Security Architect
>> DataPower Technology       http://www.datapower.com
>> XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
>> XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
>>
>>
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Monday, 29 November 2004 16:12:00 UTC