You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Philipp Schöpf <Ph...@gmx.de> on 2006/09/27 23:22:56 UTC
Working with digitally signed SDO content
Hi,
while playing around with SDOs it came into my mind that it would be fancy to process digitally signed XML content using SDO API. Unfortunately it seems like SDO is somehow "restructuring" the XML when it is serialized from XML to SDO (e.g. re-formatting or moving namespace declarations etc.) and thus makes sucessful validation of the digital signature impossible, afterwards. I guess this is a restriction of the underlying EMF, correct?
Is there any workaround to solve this issue ? I thought about open/ mixed content but didn't give it a try, yet. Or are there any plans to support "stable" XML infosets in future?
Best regards,
Philipp
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Working with digitally signed SDO content
Posted by Philipp Schöpf <ph...@gmx.de>.
Hi Kelvin,
thanks for the reply.
The whole stuff came into my mind when I thought about using SDO to model
elements of the SAML specification
(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security).
SAML Types may contain XML digital signature elements, for example as shown
below
<element name="Assertion" type="saml:AssertionType"/>
<complexType name="AssertionType">
<sequence>
<element ref="saml:Issuer"/>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="saml:Subject" minOccurs="0"/>
<element ref="saml:Conditions" minOccurs="0"/>
....
<complexType name="ResponseType">
<complexContent>
<extension base="samlp:StatusResponseType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="saml:Assertion"/>
In the example case, a ResponseType may contain a SAML AssertionType which
further may be digitally signed containing an XML digital signature element.
If SDO would have supported "stable" literal information, it would have been
possible to take an incoming XML ResponseType, serialize it to an SDO and
check the contained AssertionType SDO for its correctness. The check-
algorithm would therefore have to deserialize the AssertionType back to XML
in oder to generate checksum information that would have to be compared to
the original checksum. Again, this all would only work if the original XML
structure of the assertion could be reconstructed, which is not the case
with SDO. I think I somewhere saw something similar done with the Apache
XMLBeans which if I remember correctly support such conversions (I am not
totally sure, I have to admit).
So a "workaround" when using SDO in such scenarios would be to check the XML
signature when it is still "on the wire" and before its serialized to SDO.
I hope this clarified my original intention of the question a bit more.
best regards,
Philipp
----- Original Message -----
From: "kelvin goodson" <ke...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, September 28, 2006 10:18 AM
Subject: Re: Working with digitally signed SDO content
Hi Phillip,
it would be good to understand in a bit more detail what your
suggestion/requirement is. SDO itself can't handle round tripping XML ->
SDO -> XML in the literal space, but only guarantees to regenerate an XML
rendition which is equivalent in the value space. Any signature attached to
an incoming XML serialized document would only relate to that particular
serialized rendition of the document so I'm struggling to see where SDO can
help, but perhaps I have missed the point.
Regards, Kelvin.
On 27/09/06, "Philipp Schöpf" <Ph...@gmx.de> wrote:
>
> Hi,
>
> while playing around with SDOs it came into my mind that it would be fancy
> to process digitally signed XML content using SDO API. Unfortunately it
> seems like SDO is somehow "restructuring" the XML when it is serialized
> from
> XML to SDO (e.g. re-formatting or moving namespace declarations etc.) and
> thus makes sucessful validation of the digital signature impossible,
> afterwards. I guess this is a restriction of the underlying EMF, correct?
> Is there any workaround to solve this issue ? I thought about open/ mixed
> content but didn't give it a try, yet. Or are there any plans to support
> "stable" XML infosets in future?
>
>
> Best regards,
>
> Philipp
>
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Working with digitally signed SDO content
Posted by kelvin goodson <ke...@gmail.com>.
Hi Phillip,
it would be good to understand in a bit more detail what your
suggestion/requirement is. SDO itself can't handle round tripping XML ->
SDO -> XML in the literal space, but only guarantees to regenerate an XML
rendition which is equivalent in the value space. Any signature attached to
an incoming XML serialized document would only relate to that particular
serialized rendition of the document so I'm struggling to see where SDO can
help, but perhaps I have missed the point.
Regards, Kelvin.
On 27/09/06, "Philipp Schöpf" <Ph...@gmx.de> wrote:
>
> Hi,
>
> while playing around with SDOs it came into my mind that it would be fancy
> to process digitally signed XML content using SDO API. Unfortunately it
> seems like SDO is somehow "restructuring" the XML when it is serialized from
> XML to SDO (e.g. re-formatting or moving namespace declarations etc.) and
> thus makes sucessful validation of the digital signature impossible,
> afterwards. I guess this is a restriction of the underlying EMF, correct?
> Is there any workaround to solve this issue ? I thought about open/ mixed
> content but didn't give it a try, yet. Or are there any plans to support
> "stable" XML infosets in future?
>
>
> Best regards,
>
> Philipp
>
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>