A few days ago I started to read the Web Services Security: SAML Token Profile 1.1 [PDF], just to discover that it was far more complicated than I had expected (I am naive) and in particular that I didn't have the sufficient understanding of Confirmation Method Identifiers
, so before reading further I had to return to the SAML V2.0 specifications. This post covers what I found, which is surprisingly little.
Trying to take this from the top, the <SubjectConfirmation> which is a child element of <Subject>, is defined as (in [SAMLCore] in section '2.4.1.1'):
The
<SubjectConfirmation>element provides the means for a relying party to verify the correspondence of the subject of the assertion with the party with whom the relying party is communicating. It contains the following attributes and elements:Method [Required]
A URI reference that identifies a protocol or mechanism to be used to confirm the subject. URI references identifying SAML-defined confirmation methods are currently defined in the SAML profiles specification [SAMLProf].
The XML Schema representation of this is:
90 <element name="SubjectConfirmation" type="saml:SubjectConfirmationType"/> 91 <complexType name="SubjectConfirmationType"> 92 <sequence> 93 <choice minOccurs="0"> 94 <element ref="saml:BaseID"/> 95 <element ref="saml:NameID"/> 96 <element ref="saml:EncryptedID"/> 97 </choice> 98 <element ref="saml:SubjectConfirmationData" minOccurs="0"/> 99 </sequence> 100 <attribute name="Method" type="anyURI" use="required"/> 101 </complexType>
I've reread both the element description several times and it still isn't clear what this is really about, but the Method XML attribute carries an identifier for the means as an protocol or mechanism.
Before diving deeper let's make it clear where it's used. The SubjectType carries it, but the XML Schema representation is not as simple as the description in SAMLCore:
77 <complexType name="SubjectType"> 78 <choice> 79 <sequence> 80 <choice> 81 <element ref="saml:BaseID"/> 82 <element ref="saml:NameID"/> 83 <element ref="saml:EncryptedID"/> 84 </choice> 85 <element ref="saml:SubjectConfirmation" minOccurs="0" maxOccurs="unbounded"/> 86 </sequence> 87 <element ref="saml:SubjectConfirmation" maxOccurs="unbounded"/> 88 </choice> 89 </complexType>
It can occur at two levels and according to the Schema it is in fact required (the last one) and is unbounded as described, so it's possible to have many means to verify the correspondence.
As stated the SAML-defined confirmation methods can be found in Profiles for the OASIS SAML V2.0. Here I had hoped for some more in depth description, but that's not really the case. Go have a read for yuorself, but I'll not dwelve at it because there are actually no less than three erratas this chapter (and also some to SAMLCore):
Three SAML-defined Confirmation Method Identifiers
are listed in chapter 3:
urn:oasis:names:tc:SAML:2.0:cm:holder-of-keyurn:oasis:names:tc:SAML:2.0:cm:sender-vouchesurn:oasis:names:tc:SAML:2.0:cm:bearer
Bearer
The term bearer is not intuitive to me, the best bet for the danish term is 'drager, 'ihændehaver' or 'overbringer'. The description is:
The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using the attributes that MAY be present in the
element, as defined by [SAMLCore].
sender-vouches
This more clearly described:
Indicates that no other information is available about the context of use of the assertion. The relying party SHOULD utilize other means to determine if it should process the assertion further, subject to optional constraints on confirmation using the attributes that MAY be present in the <SubjectConfirmationData> element, as defined by [SAMLCore].
holder-of-key
Finally urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
One or more <ds:KeyInfo> elements MUST be present within the <SubjectConfirmationData> element. An xsi:type attribute MAY be present in the <SubjectConfirmationData> element and, if present, MUST be set to saml:KeyInfoConfirmationDataType (the namespace prefix is arbitrary but must reference the SAML assertion namespace).
The referenced parts are in XML Schema:
102 <element name="SubjectConfirmationData" type="saml:SubjectConfirmationDataType"/> 103 <complexType name="SubjectConfirmationDataType" mixed="true"> 104 <complexContent> 105 <restriction base="anyType"> 106 <sequence> 107 <any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 108 </sequence> 109 <attribute name="NotBefore" type="dateTime" use="optional"/> 110 <attribute name="NotOnOrAfter" type="dateTime" use="optional"/> 111 <attribute name="Recipient" type="anyURI" use="optional"/> 112 <attribute name="InResponseTo" type="NCName" use="optional"/> 113 <attribute name="Address" type="string" use="optional"/> 114 <anyAttribute namespace="##other" processContents="lax"/> 115 </restriction> 116 </complexContent> 117 </complexType>
and
118 <complexType name="KeyInfoConfirmationDataType" mixed="false"> 119 <complexContent> 120 <restriction base="saml:SubjectConfirmationDataType"> 121 <sequence> 122 <element ref="ds:KeyInfo" maxOccurs="unbounded"/> 123 </sequence> 124 </restriction> 125 </complexContent> 126 </complexType>
This isn't as clear as I had hoped, but then I found a Shibboleth wiki entry by Scott Cantor on SubjectConfirmation that does a much better job on describing holder-of-key
SubjectConfirmation attaches specific security technologies and constraints to an assertion such that it becomes not only a stand-alone package of information but also a SecurityToken. That is, an entity can use it to prove something about itself to a relying party in order to accomplish some task.
An example illustrates this. Imagine an X.509 certificate. The certificate combined with the private key is a security token. A client can prove ownership of the key, and by attaching the certificate, the relying party can accept the claims inside the certificate if it trusts the issuer.
By itself, a SAML assertion resembles a certificate, but it lacks the key material. The client can't do anything to prove its right to use the assertion. SubjectConfirmation can be used to extend the SAML assertion into the security-specific domain of public key cryptography. By embedding a public key inside a HolderOfKey SubjectConfirmation , the issuer enables a client that can prove ownership of the key to use the assertion, while nobody else can do so. This doesn't turn the assertion into a certificate, but it connects a particular security layer (public key crypto) with SAML, resulting in a SecurityToken.
Note that the security layer could be "null", as in the case of a BearerSubjectConfirmation. This grants anybody holding the assertion the ability to use it (subject to other constraints). Thus, any assertion can be turned into a weak SecurityToken by including a BearerSubjectConfirmation.
I would like to say that thes explains it all to me, but it doesn't. The first part talks on generating a general security token. This matches the use in what i startet this post with, the SAML token profile for WSS. The last part though say that urn:oasis:names:tc:SAML:2.0:cm:bearer makes it a weak security token.
I can only conclude that what I had hoped to be an easy readup has just confused me at a higher level. For now I'll just accept the three known Confirmation Method Identifiers, and then later some day I'll me stuble upon some information that can clarify it for me.
0 comments :
Post a Comment