Jesus Rodriguez's WebLog

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:

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:          <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.

As you might have noticed, I haven't been actively blogging during the last month. The reason is that I have been hands on working on a very ambitious project to showcase Web Services interoperability between Microsoft and Oracle platforms. This experiment allowed us to explore the interoperability of WCF 4.0 and WIF RTM with the upcoming release of Oracle WebLogic within the context of a real world application. As a result, we were able to implement various complex WS interoperability scenarios encompassing diverse areas such as security, trust, federation, asynchronous reliable messaging, transactions, etc. We had the opportunity to experience firsthand the interop capabilities of both stacks as well as identify some of the areas that require improvement in order to achieve better levels of interoperability.

Our final demo scenario was highlighted this week by both Microsoft and Oracle at Gartner's Application Architecture Development and Integration Summit in Las Vegas. The details of our sample application should be available in the upcoming weeks.

During the development process, I had the opportunity of working alongside members of the WCF, WIF and WebLogic product teams and I am very thankful for the experience. Big kudos to Kent Brown for sponsoring such an ambitious project and trusting Tellago with the responsibility of delivering under such a very aggressive deadline. On our side, I had a great backup from Nicolas Salazar who implemented the user interfaces used to test the interop scenarios.