nasty dot net 4.0 “bug” in saml1.1 token verification- tunneling attributes within attribute values


at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3)
at System.Xml.XmlUTF8TextReader.Read()
at System.Xml.XmlBaseReader.MoveToContent()
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.SetDelegateFromAttribu(SamlAttribute attribute, IClaimsIdentity subject, String issuer)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ProcessAttributeStatement(SamlAttributeStatement samlStatement, IClaimsIdentity subject, String issuer)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ProcessStatement(IList`1 statements, IClaimsIdentity subject, String issuer)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
at WebRole1.About.Page_Load(Object sender, EventArgs e) in c:\Users\Administrator.RAPMLSQA\Desktop\WindowsAzure3\WebRole1\About.aspx.cs:line 237

This took me 4 hours to find out what the above really means! The information comes from a stack trace associated with a XML deserialization exception, raised when performing a verifyToken method.

Basically verifytoken method threw a strange error, reporting an xml parsing error.  But. the assertion is well formed (and signs/verifies etc). For a while I had thought that, indeed, somehow some attribute’s own formatting was itself inappropriate. But, on the face of it and as shown below, none of them appear weird – syntactically.

But  we do indeed learn form the web that’s its possible for there to be attribute value syntaxes whose syntax is “undeclared” (in the outer language) – if one uses “special attributes” claimtypes (names):

Our bug was due to mis-applying just obe of these attribute in the authorization statement – with those highlighted being the only unusual ones added by this unique STS.


Lets guess the weirdo is “actor” (mostly since Microsoft documentation disclosures say nothing of any use, and there is usually a reason for that ). And of course actor is a field used in SOAP headers, regularly.


We see that from an example that indeed (and this justifies the particular exception seen), that the actor attribute’s value is an xml document:


We have thus learned how now to tunnel a set of attributes (each augmented with additional properties) through a “tunnel-bearer” attribute value:


So obviously we can fix the bug! But, we also learned lots about advanced WIF!


About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in SAML. Bookmark the permalink.