[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [saml-dev] Signing Assertions
Hi, I was looking at how assertions are signed by an authority, the core draft (draft-sstc-core-28.pdf) states "SAML assertions and protocols MUST use the enveloped signatures for signing assertions and protocols" Here's the scenario I'm interested in: The client obtains an assertion from the authority, this assertion contains an enveloped signature, the client then uses this assertion in a soap message (to access a WebService) which itself is signed by the client, in other words the soap message contains two signatures, one for the whole soap message and one for actual assertion. I was playing around with Netegrity's JSAML toolkit (version 1.01), and they have an example of this: <?xml version="1.0" encoding="UTF-8" ?> - <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> - <SOAP-ENV:Header> - <saml:AssertionList AssertionID="192.168.0.131.1010924615489" IssueInstant="2002-01-13T12:23:35Z" Issuer="M and M Consulting" MajorVersion="1" MinorVersion="0" xmlns:saml="http://www.oasis-open.org/committees/security/docs/draft-sstc-sc hema-assertion-16.xsd"> + <saml:Conditions NotBefore="2002-01-13T12:18:35Z" NotOnOrAfter="2002-01-13T12:33:35Z"> + <saml:AuthenticationStatement AuthenticationInstant="2002-01-13T12:23:35Z" AuthenticationMethod="Password"> + <saml:AuthorizationStatement Decision="Permit" Resource="SpendingLimit"> - <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> - <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000119" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> + <Reference URI=""> </SignedInfo> <SignatureValue>Qv8ZR+mLWMSTxA/QZNPFtkQCwmAjKFg0VEQazqwCk2+PNzwagCpJPA==</Si gnatureValue> + <KeyInfo> </Signature> </saml:AssertionList> </SOAP-ENV:Header> + <SOAP-ENV:Body> - <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> - <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000119" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> + <Reference URI=""> </SignedInfo> <SignatureValue>VLEs9YTdSlhWt3NbpCq3w42nOA9PgEXMR/ITiXwpPeb2s45clZEJzw==</Si gnatureValue> + <KeyInfo> </Signature> </SOAP-ENV:Envelope> I know some of the tags are out of date, the toolkit was based on draft version 16, does anyone know if Netegrity are thinking of bringing out a new version of this toolkit, to support the final draft? Anyway, my question is what would happen if you passed the above soap envelope to a signature validator? The outer signature would pass (the one from the client) but surely the signature that was originally associated with the assertion (the one from the authority) would fail. This is because that signature contains the following: <Reference URI="">, which essentially states that the signature is associated with the whole document. That may have been true when the assertion and associated signature were on their own, but once it was placed inside a soap message then this reference is no longer valid. i.e. The message now contains two Signatures that both claim to have signed the whole document. I suppose the question is, when the authority signs an assertion, should they put in a reference to the assertion itself, or a transform such as XPath (using exc-C14n) which identifies the assertion fragment as a seperate piece of XML from the SOAP envelope or other context? If they use the above format (the null URI), then you can never take an assertion with a signature and put it into another document, as it breaks the signature. Any answers/thoughts on this would be great, Karl. Karl Nesbitt Ph.D. Vordel Web services security karl.nesbitt@vordel.com Ph: + 353 1 215 3316 Fax: + 353 1 215 3334 http://www.vordel.com Cranford Court Dublin 4 Ireland Check out our career opportunities at: http://www.vordel.com/careers/index.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC