SubjectConfirmation

SubjectConfirmation was an obscure feature of SAML 1.x that wasn't very well understood. The schema itself was incorrect in a number of areas, which limited its usefulness, and so in SAML 2.0, the schema was reworked and the concept was expanded and clarified.

In practical terms, what SubjectConfirmation says is "these are the conditions under which an attesting entity (somebody trying to use the assertion) is permitted to do so". The "wielder" is attesting to its right to use the assertion, usually by implying a relationship with the subject. An assertion can have any number of SubjectConfirmation elements, but an attesting entity only has to satisfy one of them.

In SAML, the SubjectConfirmation element is a child of the Subject element. The following is an example of a SAML 1.x Subject element:

  <!-- SAML 1.x Subject with SubjectConfirmation -->
  <Subject>
	 <NameIdentifier
		Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
		user@example.org
	 </NameIdentifier>
	 <SubjectConfirmation>
		<ConfirmationMethod>
		  urn:oasis:names:tc:SAML:1.0:cm:bearer
		</ConfirmationMethod>
	 </SubjectConfirmation>
  </Subject>

In SAML 2.0, an equivalent Subject element is formulated as follows:

  <!-- SAML 2.0 Subject with SubjectConfirmation -->
  <Subject>
	 <NameID
		Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
		user@example.org
	 </NameID>
	 <SubjectConfirmation
		Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
  </Subject>

Note that the ConfirmationMethod element in SAML 1.x has given way to the SAML 2.0 Method attribute. Another difference is that the SubjectConfirmation element in SAML 2.0 may itself contain NameID elements (which is useful in more complex scenarios such as MetaSearch).

Confirmation Method Identifiers

SAML 1.x defines four subject confirmation method identifiers:

  urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
  urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
  urn:oasis:names:tc:SAML:1.0:cm:artifact
  urn:oasis:names:tc:SAML:1.0:cm:bearer

The artifact and bearer identifiers MUST be used in the SAML 1.x Browser/Artifact and Browser/POST profiles, respectively.

SAML 2.0 redefines three of the four SAML 1.x confirmation method identifiers:

  urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
  urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
  urn:oasis:names:tc:SAML:2.0:cm:bearer

The artifact confirmation method identifier was dropped since the browser profiles were consolidated in SAML 2.0. The bearer identifier MUST be used in the SAML 2.0 SSO Profile, regardless of binding.

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.

%COMMENT%