SAML assertions defined in the SAML Token Profile standard

WAS v8.5 > Secure applications > Secure web services > Secure web services > Web Services Security concepts > SAML concepts
SAML assertions defined in the SAML Token Profile standard

SAML assertions are used as tokens in the <wsse:Security> header block.

Token Description
bearer Proof of the relationship between the subject and claims is implicit and no steps are taken to establish the relationship. If protection of messages is required, use transport level protection, or use a non-SAML security token, such as an X.509 or Kerberos token, for message level protection.
holder-of-key Proof of the relationship between the subject and claims is established by signing part of the SOAP message with the key specified in the assertion. This token can be used to provide message level protection (signing and encryption) of the SOAP message.
sender-vouches The server propagates both client identity and client attributes. The attesting entity protects the vouched for assertions and message content. The receiver verifies that it has not been altered by another party. We can ensure message protection either at the transport level or the message level.

XML signatures use assertions to bind subjects and statements to SOAP messages. Subject confirmation methods provide proof of the relationship between the subject and the claims of the assertions.

sender-voucher

With a sender-voucher the receiver verifies that one of the following scenarios occurs:

A sender sets up a SSL session with a receiver using client certificate authentication.
A sender digitally signs assertions with the containing SOAP message using security token reference transformation algorithm. A sender can use either SSL or SOAP message encryption to protect confidentiality.
In either case, the assertions are either issued by an external security token services (STS) or self- issued by the application server.

Bearer assertion

A SAML assertion v1.0 is a bearer assertion if it includes the bearer <saml:ConfirmationMethod> element.
<saml:SubjectConfirmation> 
    <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod> 
</saml:SubjectConfirmation>
A SAML v2.0 bearer assertion contains:
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> </saml2:SubjectConfirmation>
Holder-of-key assertion

A SAML assertion is a holder-of-key assertion if it includes the SubjectConfirmation element containing a saml:ConfirmationMethod element with the value of holder-of-key, and a ds:KeyInfo element.
The ds:KeyInfo information inside the SubjectConfirmation element identifies a public or secret key that confirms the identity of the subject. The holder-of-key assertion also contains a ds:Signature element that protects the integrity of the confirmation ds:KeyInfo element as established by the assertion authority.
A SAML v1.1 holder-of-key assertion must contain the following SubjectConfirmation element:
<saml:SubjectConfirmation> 
  <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm: holder-of-key </saml:ConfirmationMethod>   
      <ds:KeyInfo>   
          <ds:KeyValue>
          . . .
          </ds:KeyValue>   
      </ds:KeyInfo> 
  </saml:SubjectConfirmation> 
A SAML v2.0 holder-of-key assertion must contain the following SubjectConfirmation element:
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">     
    <saml2:SubjectConfirmationData>    
        <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">                     
            ......
        </ds:KeyInfo>      
</saml2:SubjectConfirmationData> </saml2:SubjectConfirmation>
Sender-vouches assertion

A SAML assertion is a sender-vouches assertion if it includes the sender-vouches <saml:ConfirmationMethod> element. A SAML v1.1 sender-vouches assertion must contain the following SubjectConfirmation element:
<saml:SubjectConfirmation> 
    <saml:ConfirmationMethod> 
        urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
    </saml:ConfirmationMethod> 
</saml:SubjectConfirmation>
A SAML v2.0 sender-vouches assertion must contain the following SubjectConfirmation element:
<saml2:SubjectConfirmation 
    Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"> 
</saml2:SubjectConfirmation>
Symmetric key in the holder-of-key assertion
A SAML holder-of-key assertion is used as a protection token. This type of protection token can use a symmetric key as a proof key. The client uses the proof key to demonstrate to the relying party the client actually owns the issued SAML token. When a security token service (STS) issues a SAML token that uses a symmetric proof key, the token contains a key that is encrypted for the target service. The STS also sends the same proof key to the requester in a <RequestedProofToken> element as part of the RequestSecurityTokenResponse (RSTR). The web service client then presents the SAML token to the target service, also known as the relying party, and signs the application message with the received proof key.
The STS can be pre-configured to issue a symmetric proof key. Typically, the following two parameters are specified inside the RequestSecurityTokenTemplate in the RequestSecurityToken (RST) when the symmetric key is requested from the STS:
<t:KeyType> http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey </t:KeyType> 
<t:KeySize>256</t:KeySize>      
The following sample SubjectConfirmation element contains a SymmetricKey encrypted for the relying party.
<saml:SubjectConfirmation>       
    <saml:ConfirmationMethod>
        urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
    </saml:ConfirmationMethod> 
          <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">              

    <enc:EncryptedKey xmlns:enc="http://www.w3.org/2001/04/xmlenc#">              
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">           
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />              
    </enc:EncryptionMethod>           

    <ds:KeyInfo>             
        <ds:X509Data>               
        <ds:X509Certificate>MIIB3...vO3bdg</ds:X509Certificate>             
        </ds:X509Data>           
    </ds:KeyInfo>      

    <enc:CipherData>          
    <enc:CipherValue>P5Kb...rOTvII</enc:CipherValue> 
            </enc:CipherData>             
    </enc:EncryptedKey>      
    </ds:KeyInfo> 
</saml:SubjectConfirmation>
Public key in the holder-of-key assertion
When a SAML holder-of-key assertion is used as a protection token, the token can use a public key as a proof key. The client uses the proof key to demonstrate to the relying party the client actually owns the issued SAML token. The advantage of a public proof key over a symmetric key is the client does not share the secret key with the security token service (STS) and relying party. The public proof key can be an X509 certificate, or a Rivest Shamir Adleman (RSA) public key.
The STS can be pre-configured to issue a public key proof key. Typically, the parameter <t:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</t:KeyType> is specified inside a RequestSecurityTokenTemplate as part of the RequestSecurityToken (RST) when the public key is requested from the STS. The optional UseKey element could also be used by the client to indicate the key, as follows:
<trust:UseKey>     
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">       
        <X509Data>         
            <X509Certificate>MIIGCzCCBPOgAwIBAgIQcSgVwaoQv6dG. . .1GqB </X509Certificate>       
        </X509Data>     
    </KeyInfo> 
</trust:UseKey> 
The following example is a SubjectConfirmation containing a PublicKey proof key.
<saml:SubjectConfirmation>          
    <saml:ConfirmationMethod>
        urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
    </saml:ConfirmationMethod> 
            
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">                 
        <ds:KeyValue>                     
            <ds:RSAKeyValue>                       
            <ds:Modulus>hYHQm. . . ZnH1S0=</ds:Modulus> 
            <ds:Exponent>AQAB</ds:Exponent> 
            </ds:RSAKeyValue>                 
        </ds:KeyValue>             
    </ds:KeyInfo> 
</saml:SubjectConfirmation>
Related

Create a SAML bearer token
Create a SAML holder-of-key token
SAML holder-of-key symmetric key token
Create a SAML sender-vouches token
SAML v1.1
SAML v2.0.

+
Search Tips | Advanced Search

Token	Description
bearer	Proof of the relationship between the subject and claims is implicit and no steps are taken to establish the relationship. If protection of messages is required, use transport level protection, or use a non-SAML security token, such as an X.509 or Kerberos token, for message level protection.
holder-of-key	Proof of the relationship between the subject and claims is established by signing part of the SOAP message with the key specified in the assertion. This token can be used to provide message level protection (signing and encryption) of the SOAP message.
sender-vouches	The server propagates both client identity and client attributes. The attesting entity protects the vouched for assertions and message content. The receiver verifies that it has not been altered by another party. We can ensure message protection either at the transport level or the message level.