OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [saml-dev] Signing Assertions


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
- <SOAP-ENV:Header>
	- <saml:AssertionList AssertionID=""
IssueInstant="2002-01-13T12:23:35Z" Issuer="M and M Consulting"
MajorVersion="1" MinorVersion="0"
	+ <saml:Conditions NotBefore="2002-01-13T12:18:35Z"
	+ <saml:AuthenticationStatement
	+ <saml:AuthorizationStatement Decision="Permit" Resource="SpendingLimit">
	- <Signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
		- <SignedInfo>
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000119"; />
  		<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1";
		+ <Reference URI="">

		+ <KeyInfo>
+ <SOAP-ENV:Body>
- <Signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
	- <SignedInfo>
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000119"; />
	<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"; />
	+ <Reference URI="">

	+ <KeyInfo>

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 Nesbitt Ph.D.
Web services security
Ph:  + 353 1 215 3316
Fax: + 353 1 215 3334
Cranford Court
Dublin 4  Ireland

Check out our career opportunities at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC