Implementing a SAML sender-vouches scenario with WIF

Sender-vouches is one of the two subject confirmation methods included in the SAML security token profile specification. Essentially, the sender-vouches scenario enables an attesting entity to vouch for the identity of a subject to a relying party. The following figure illustrates this scenario:

sender-vouches[1]

From the protocol standpoint, an attesting entity uses the sender-vouches confirmation method to assert that it is acting on behalf of the subject of SAML statements attributed with a sender-vouches SubjectConfirmation element. The SAML statements attested by the sender-vouches method must have a corresponding more sender-vouches SubjectConfirmation elements. The following code illustrates a security token that uses the sender-vouches confirmation method.

   1: <wsse:Security>
   2:    <saml:Assertion AssertionID="SAML_ID" Issuer="www.example.org" ...>
   3:       <saml:Conditions NotBefore="..." NotOnOrAfter="..."/>
   4:       <saml:AuthenticationStatement AuthenticationMethod="urn:...:password"
   5:                                     AuthenticationInstant="2005-03-19T...Z"
   6:          &lt;saml:Subject>
   7:             <saml:NameIdentifier>Sample ID</saml:NameIdentifier>
   8:             <saml:SubjectConfirmation>
   9:                <saml:ConfirmationMethod>
  10:                   urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
  11:                </saml:ConfirmationMethod>
  12:             </saml:SubjectConfirmation>
  13:          </saml:Subject>
  14:       </saml:AuthenticationStatement>
  15:    </saml:Assertion>
  16:    <wsse:SecurityTokenReference wsu:Id="STR1" ...> ... </wsse:SecurityToken..>
  17:    <wsse:BinarySecurityToken ...> ... </wsse:BinarySecurityToken>
  18:    <ds:Signature>
  19:       <ds:SignedInfo>
  20:          <ds:Reference URI="#STR1"> ... </ds:Reference>
  21:          <ds:Reference URI="#body"> ... </ds:Reference>
  22:          ...
  23:       </ds:SignedInfo>
  24:    </ds:Signature>
  25: </wsse:Security>

As you can see in line 10, the subject confirmation element of the authentication statement is set to urn:oasis:names:tc:SAML:1.0:cm:sender-vouches.

The sender-vouches confirmation method is relevant to a variety of identity management scenarios and it's particularly relevant in message brokering mechanisms on which messages between a subject and a relying party are routed through an intermediary.

The current version of the Windows Identity Foundation(WIF) does not include default support for the sender-vouches confirmation method. However, this method can be easily enabled by leveraging WIF extensibility mechanisms. Specifically, we can extend the default SAML token handlers in order to generate a SAML assertion that includes the sender-vouches confirmation method. The following code illustrates this technique in order to generate a SAML 1.1 security token.

   1: public class SenderVouchesSaml11TokenHandler: Saml11SecurityTokenHandler
   2: {
   3:  
   4:   public override bool CanValidateToken
   5:   {
   6:     get
   7:       {
   8:         return true;
   9:       }
  10:     }
  11:  
  12:    public override string[] GetTokenTypeIdentifiers()
  13:    {
  14:      return new string[2]{Consts.cSAML11TokenType, Consts.cSAML11Assertion};
  15:    }
  16:  
  17:  
  18:  
  19:    public override ClaimsIdentityCollection ValidateToken(SecurityToken token)
  20:    {
  21:      SamlSecurityToken samlToken = token as SamlSecurityToken;
  22:      IClaimsIdentity claimsIdentity = this.CreateClaims(samlToken);
  23:      return new ClaimsIdentityCollection
  24:                     (new List<IClaimsIdentity> { claimsIdentity });
  25:  
  26:    }
  27:  
  28:  
  29:    protected override System.IdentityModel.Tokens.SamlSubject
  30:                     CreateSamlSubject(SecurityTokenDescriptor tokenDescriptor)
  31:    {
  32:   SamlSubject subject = new SamlSubject(Consts.cUnspecifiedNameIdentifier, 
  33:                                              Consts.cNameQualifier, "Alice");
  34:  subject.ConfirmationMethods.Clear();
  35:  subject.ConfirmationMethods.Add("urn:oasis:names:tc:SAML:1.0:cm:sender-vouches");
  36:            
  37:  return subject;
  38:    }
  39:  
  40:    protected override System.IdentityModel.Tokens.SamlAuthenticationStatement 
  41:             CreateAuthenticationStatement(System.IdentityModel.Tokens.SamlSubject  
  42:             samlSubject, IdentityModel.Claims.AuthenticationInformation authInfo, 
  43:             IdentityModel.Tokens.SecurityTokenDescriptor tokenDescriptor)
  44:     {
  45:     SamlAuthenticationStatement authStatement = new SamlAuthenticationStatement();
  46:     authStatement.AuthenticationMethod = 
  47:               Saml11Constants.AuthenticationMethods.UnspecifiedString;
  48:   authStatement.SamlSubject = samlSubject;
  49:     return authStatement;
  50:         }
  51:  
  52:         ....
  53:     }

Essentially, we need to override the CreateSamlSubject in order to create a subject that includes the sender-vouches confirmation method. After that, we just need to associated that subject with the authentication statement. After implementing the token handler we only need to add it to the STS configuration security token handlers pipeline.

config.SecurityTokenHandlers.AddOrReplace(new SenderVouchesSaml11TokenHandler());

This technique can also be applied for a SAML 2.0 token handler.

5 Comments

  • In this use case, does STS has trust relationship with the Attesting Entity?

    Do you also need to supply the credential of the Attesting Entity to the STS other than the credential of the Subject to the STS?

    How do STS tells apart the Subject credentials from Attesting Entity credentials in the message?

    I think ActAs/OnbehalfOf mechanisms are more proper for this type of scenarios. It is STS instead of the Attesting entity who signs the SAML assertion to certify it.


  • The subtle difference between two cases:

    1. Sender-Vouches: the intermediary has trust relationship with the RP, but no (or not necessarily) has trust relationship with STS.

    2. ObBehalf/ActAs: the intermediary has a trust relationship with the STS, but no (or not necessarily) has trust relationship with the RP.

    It is interesting to have a unified way to support both the cases with STS. It is hard coded in the sample.

  • Hi, I need to have help from someone that have a good know how about wcf service security.

    My problem, I have an WCF-Service that must operate in a ws-security context with SOAP + SAML + Sender Vouches. But, my wcf service work in a java context with the mentioned conditions and I must validate an incomming call (Java -SOAP+SAML+Sender Vouches) from Java Client. I hope that you can help me?

    I think what I need, are only to configure my wcf service to support ws-security wit SOAP+SAML+Sender Vouches?

  • Good stuff.

    Would you happen to have sample code to go with this article? I'm trying to implement this on my own, and some sample code will really help..

  • Never mind. I got it working now..

Comments have been disabled for this content.