RE: Composibility problems with refps

> Okay, I am baffled now. If the EPR ref props/params are XML, how is it
> then that they are any different
> than say a WS-RM Sequence header?

Because you can look at that header and by its qname know that it is part
of WS-RM.  (Which WS-RM is another matter :).  You *cannot* do the same
thing with ref props/params.  You cannot look at an arbitrary SOAP header
and tell if it was part of WS-Addressing.  Therefore, pragmatically, you
cannot implement a security policy that secures WS-Addressing.  Consider
that refparams can very per operation, and refprops can very per instance.

Can you show me how you might (granted, you're not shipping working code
for this yet) configure WebSphere to secure (either via signing or
encryption, I'll take either one) ws-addressing information?

> My point was that any
> service that had been compromised as he described is screwed anyway
> regardless of the fact that it could
> insert some malicious ref prop/param.

Maybe.  One could easily imagine low-value SOAP headers that does not need
protection.  I dunno, something like "preferred CSS URI" or "favorite
background color" or some such.  Whatever.  I do not think it is
reasonable for WS-Addressing to require that any application using
WS-Addressing must now use WS-Security to secure *all* SOAP headers, just
because WS-Addressing doesn't make it easy for the security layer to find
the addressing information.

As for "EPR minter signs the data", do you mean that if there are "n" ref
props/params, you get back n+1 elements, where the new one is a XML DSIG
that covers the other n?  How do you prevent replay attacks, since the
minter has no way tie the signature to the message?  How do you integrate
this into ws-security?  After all, you're now doubling the amount of trust
points that the receiver has to know about, in essence introducing a
trusted third party into every application that wants to use secure
ws-addressing.  If I understand what you mean, then I don't think that's a
reasonable thing to do because of the questions I asked in this paragraph.
Not only that, you're adding significantly to the size of the message (a
couple of kilobytes) by adding another signature.

	/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

Received on Thursday, 25 November 2004 03:53:35 UTC