Thursday, July 26, 2007

SAML V2.0 Assertion example from "E-Authentication Federation Architecture 2.0 Interface Specifications"

pencil icon, that"s clickable to start editing the post

In the new interface specification there are several examples and one of them are of a SAML V2.0 Assertion. Examples are often great eye openers because it enables the possibility to reverse the learning from the top-down reading to What's that I'll have a look at that first and ofcourse the ahh, it's just that simple.

The example is very hard to read because of redundant namespace declaration cluttering the real content, and forcing it into three PDF pages doesn't help. The example also isn't well formed because the closing tag to <ds:X509Certificate> has somehow been abbreviated to </ds:X59Certificate>. Fixing this, cleaning up the namespace declarations to the minimum and adding schemaLocation references, makes the example much simpler to read and possible to validate.

    1 <?xml version="1.0" encoding="utf-8"?>
    2 <saml:Assertion
    3   ID="i1a8cbc7ffe5e97f8c177792eefe1cd4b21109d93"
    4   IssueInstant="2007-02-15T19:21:59.000Z"
    5   Version="2.0"
    6   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    7   xmlns:xsd=""
    8   xmlns:xsi=""
    9   xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:assertion
   11    urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500">
   12   <saml:Issuer></saml:Issuer>
   13   <ds:Signature xmlns:ds="">
   14     <ds:SignedInfo>
   15       <ds:CanonicalizationMethod Algorithm="" />
   16       <ds:SignatureMethod Algorithm="" />
   17       <ds:Reference URI="#i1a8cbc7ffe5e97f8c177792eefe1cd4b21109d93">
   18         <ds:Transforms>
   19           <ds:Transform Algorithm="" />
   20           <ds:Transform Algorithm="">
   21             <ec:InclusiveNamespaces
   22               xmlns:ec=""
   23               PrefixList="xsd" />
   24           </ds:Transform>
   25         </ds:Transforms>
   26         <ds:DigestMethod Algorithm="" />
   27         <ds:DigestValue>xy+yrYU6widLMZuHBJ4lSiVfDng=</ds:DigestValue>
   28       </ds:Reference>
   29     </ds:SignedInfo>
   30     <!--
   31       !Please note that I've removed the '....' from the elements <ds:SignatureValue> and <ds:X509Certificate>
   32       to make it valid according to the XML Schema definitions
   33     -->
   34     <ds:SignatureValue>
   35       RuYlMNva0n5cHyUBy3l4h7MLGffm71gxRbT58/1nyDB53osoKgTdMf EcwGlJp4U5kmogPa7Q1SbQ
   36     </ds:SignatureValue>
   37     <ds:KeyInfo>
   38       <ds:X509Data>
   39         <ds:X509Certificate>
   40           UEvocATzqEPnAtIkRCltvFCHbOG9ctZiS1QQIGcSR0te60PfAgMBAA GjgckwgcYwCQYDVR0TBAIw
   41         </ds:X509Certificate>
   42       </ds:X509Data>
   43     </ds:KeyInfo>
   44   </ds:Signature>
   45   <saml:Subject>
   46     <saml:NameID
   47       Format="urn:oasis:names:tc:SAML:2.0:nameidformat:persistent"
   48       NameQualifier=""
   49       SPNameQualifier="">
   50       a9c16e8616880860f837a58dc12b490376d8bffa
   51     </saml:NameID>
   52     <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
   53       <saml:SubjectConfirmationData
   54         InResponseTo="s2f2e4125ad08136b30ae49893a1ae86c154f451e4"
   55         NotOnOrAfter="2007-02-15T19:31:59.000Z"
   56         Recipient="" />
   57     </saml:SubjectConfirmation>
   58   </saml:Subject>
   59   <saml:Conditions>
   60     <saml:AudienceRestriction>
   61       <saml:Audience></saml:Audience>
   62     </saml:AudienceRestriction>
   63   </saml:Conditions>
   64   <saml:AuthnStatement
   65     AuthnInstant="2007-02-15T19:21:55.000Z"
   66     SessionIndex="843AE7"
   67     SessionNotOnOrAfter="2007-02-16T05:21:55.000Z">
   68     <saml:AuthnContext>
   69       <saml:AuthnContextClassRef>
   70         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
   71       </saml:AuthnContextClassRef>
   72       <saml:AuthnContextDeclRef>
   74       </saml:AuthnContextDeclRef>
   75     </saml:AuthnContext>
   76   </saml:AuthnStatement>
   77   <saml:AttributeStatement>
   78     <saml:Attribute
   79       Name="us:gov:e-authentication:basic:assuranceLevel"
   80       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
   81       <saml:AttributeValue xsi:type="xsd:string">2</saml:AttributeValue>
   82     </saml:Attribute>
   83     <saml:Attribute
   84       Name="us:gov:e-authentication:2007:cn"
   85       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
   86       <saml:AttributeValue xsi:type="xsd:string">2</saml:AttributeValue>
   87     </saml:Attribute>
   88     <saml:Attribute
   89       Name="us:gov:e-authentication:2007:cn"
   90       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
   91       <saml:AttributeValue xsi:type="xsd:string">Alice Adams</saml:AttributeValue>
   92     </saml:Attribute>
   93     <saml:Attribute
   94       Name="us:gov:e-authentication:2007:specVer"
   95       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
   96       <saml:AttributeValue xsi:type="xsd:string">2.0</saml:AttributeValue>
   97     </saml:Attribute>
   98     <saml:Attribute
   99       Name="us:gov:e-authentication:2007:PSSN"
  100       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
  101       <saml:AttributeValue xsi:type="xsd:string">5681</saml:AttributeValue>
  102     </saml:Attribute>
  103   </saml:AttributeStatement>
  104 </saml:Assertion>

There is still alot of information and since the last piece of SAML V2.0 i looked at was the Attribute profiles, I'll have a close look at <saml:AttributeStatement>. There are five attribute statements, where the second one looks like an error, since there are two attributes with the name us:gov:e-authentication:2007:cn and the first one has the value 2, that's not very common name like whereas the second one has the value Alice Adams that looks alright (she was also used in the SAML V1.1 Interoperability Demonstration at the RSA Conference in 2004. Common Name is a term used in X.500/LDAP and it would seem obvoius to use the X.500/LDAP Attribute profile (the updated one that is, that i covered in last post). Section " Required Attributes" dictates three mandotory attributes:

  • us:gov:e-authentication:basic:assuranceLevel
  • urn:oid:
  • us:gov:e-authentication:basic:specVer

the second one is certainly of the X.500/LDAP breed as described in RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 section "5.4. cn", and the description:

This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.

which is very close to (should in practice be identical) to the definition in the interface specification

The displayable full name of the end user. In the case of assurance level 1 this may be a pseudonym.

First name followed by optional middle name or initial followed by last name delimited by spaces. MUST be <=256 characters in length.

Very few people have a common name longer than 256 characters, but the X.500 definition does allow much longer values since it's based on name like many of the other attributes and the definition is:

( NAME 'name' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX{32768} )

This is a bit confusing. For one this name isn't used in the example, whereas the example uses us:gov:e-authentication:2007:cn that can't be found as a valid attribute name in neither section " Required Attributes" nor in section " Optional Attributes". Since the URN contains 2007 i guess that it can't be a legacy issue, and so either the text or the example is correct, but I can't tell which.

Any way they want to describe common name, so why don't the follow the X.500/LDAP Attribute profile, since that what it's made for.

Directories based on the ITU-T X.500 specifications [X.500] and the related IETF Lightweight Directory Access Protocol specifications [LDAP] are widely deployed. Directory schema is used to model information to be stored in these directories. In particular, in X.500, attribute type definitions are used to specify the syntax and other features of attributes, the basic information storage unit in a directory (this document refers to these as “directory attributes”).

Directory attribute types are defined in schema in the X.500 and LDAP specifications themselves, schema in other public documents (such as the Internet2/Educause EduPerson schema [eduPerson], or the inetOrgperson schema [RFC2798]), and schema defined for private purposes. In any of these cases, it is useful for deployers to take advantage of these directory attribute types in the context of SAML attribute statements, without having to manually create SAML-specific attribute definitions for them, and to do this in an interoperable fashion.

The X.500/LDAP attribute profile defines a common convention for the naming and representation of such attributes when expressed as SAML attributes.

Maybe they don't want the X.500/LDAP common name but they're own one, or product support is lacking (conformance requirements on the Attribute profiles are unclear to me) or (in theory) they could have missed it.

The us:gov:e-authentication:basic:assuranceLevel attribute is present and correct and the last required attribute us:gov:e-authentication:basic:specVer is - ahem, well I guess the idea was that us:gov:e-authentication:2007:specVer should be it. Here's another attribute naming that's unclear, and in fact the last attribute in the example us:gov:e-authentication:2007:PSSN is also different from the best guess in the optional attributes section, where it's called us:gov:e-authentication:basic:PSSN (The last four digits of the end user’s social security number).

It's said that the power of examples are great and I generally agree, even though this example or specification needs a revision. Maybe I gather energy to go through the rest of the example some time later, but the four attributes has been more than enough fore now.