Anatomy of a SAML-Secured SOAP Message
As promised, here is a dissection of the SOAP message from yesterday’s post on the AM 7.1 Beta Secure Web Services Tutorial.
First, let’s take another look at the secured message in its entirety:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-01.xsd">
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="s69f7e258e30da2b9b9f5799d4eb0c548782432bf" IssueInstant="2006-05-24T05:52:32Z" Issuer="patlinux" MajorVersion="1" MinorVersion="1">
<saml:AuthenticationStatement AuthenticationInstant="2006-05-24T05:52:30Z" AuthenticationMethod="urn:com:sun:identity:Application">
<saml:Subject>
<saml:NameIdentifier>wsc</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName>
<KeyValue>
<RSAKeyValue>
<Modulus>AIE1oq...</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#s69f7e258e30da2b9b9f5799d4eb0c548782432bf">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>zdCY/1iqOMUJq/RvxsaDPWM4+7c=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>ApcX/D...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIICmj...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</saml:Assertion>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>Sccy9a3A7Ps27f3pf9adkRWuGvU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>aE9vKM...</SignatureValue>
<KeyInfo>
<SecurityTokenReference xmlns="http://schemas.xmlsoap.org/ws/2003/06/secext" wsu:Id="STR1">
<KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="sbee70b80d8b330875655b8956d13ff5a4199ca1d">s69f7e258e30da2b9b9f5799d4eb0c548782432bf</KeyIdentifier>
</SecurityTokenReference>
</KeyInfo>
</Signature>
</wsse:Security>
</env:Header>
<env:Body wsu:Id="se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
<ns0:QuoteRequest>
<Symbol>SUNW</Symbol>
</ns0:QuoteRequest>
</env:Body>
</env:Envelope>
It’s pretty hard to see the wood from the trees here, particularly since there are two signatures in there. Here is a somewhat abstracted version:
Working from the inside out:
- The SAML
AuthenticationStatement
contains data from a SAML authority concerning a subject - that is, the person/service/device/whatever whose identity is in question here. In theAuthenticationStatement
we can see aSubject
element containing aNameIdentifier
(which we could use to refer to this subject in future exchanges with this SAML authority) and aSubjectConfirmation
element. TheConfirmationMethod
element tells us how the assertion is bound to the subject. In this case, it is Holder of Key, indicating that theSubjectConfirmation
also carries a public key. Assuming we trust the SAML authority, we can be confident that anything we receive that is signed with the corresponding private key came from the subject. You can clearly see an RSA public key, with its modulus and exponent, in theKeyInfo
element. - Moving down, immediately after the
AuthenticationStatement
is aSignature
(white in the diagram). This is an enveloped signature over the parentAssertion
. This signature binds theAssertion
to the issuing SAML authority. It contains an X.509 certificate which we can use to verify the signature and decide if the assertion has come from a trusted SAML authority. - So, now we have an assertion that contains the public key of some subject known to a SAML authority. The next
Signature
element (blue in the diagram) is a detached signature of the SOAPBody
. This signature binds theBody
(and its payload - the actual stock request that the recipient is going to process) to the subject. ThisSignature
does not contain an X.509 certificate. Instead, it has aKeyInfo
element that references the earlierAssertion
- the recipient is to use the public key in theAssertion
to verify the signature.
The recipient thus has all the pieces it needs to verify that
- The message was not tampered with in transit
- The body was signed by some subject identified by a SAML authority identified by an X.509 certificate.
In this entry I’ve covered the stock request as it appears on the wire. Next time round I’ll look at how Access Manager 7.1’s JSR 196 provider makes all this happen in the web container (App Server) with no code in the required in your web service consumer or producer.
References
- The Web Services Interoperability Organization (WS-I) Basic Security Profile (BSP) defines an interoperable structure of secure SOAP messages. The SAML Token Profile defines the specifics as applied to SAML.
- Paul Madsen’s SAML 2: The Building Blocks of Federated Identity nicely covers some more of the background to SAML 2 and its components.
- The OASIS Security Services (SAML) TC page is the authoritative source of the SAML 2.0 specifications.
Comments
Michael
So, I’m about to dig into the the deployed WARs of the stock client and service to determine how the Access Manager JSR 196 provider makes all this happen in the web container with no code… Wanna right that follow up you teased about? Great article by the way.
Superpat
Even better than that, Michael, I'm trying to get the project-lead for the Access Manager/JSR 196 work to blog on it. I'll keep you posted.
Leave a Comment
Your email address will not be published. Required fields are marked *