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="http://www.w3.org/2001/XMLSchema" 8 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 9 xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:assertion http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd 10 http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd 11 urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500 http://docs.oasis-open.org/security/saml/v2.0/saml-schema-x500-2.0.xsd"> 12 <saml:Issuer>https://saml20.caf.eauth.enspier.net:443/IDP</saml:Issuer> 13 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 14 <ds:SignedInfo> 15 <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 16 <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> 17 <ds:Reference URI="#i1a8cbc7ffe5e97f8c177792eefe1cd4b21109d93"> 18 <ds:Transforms> 19 <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> 20 <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-excc14n#"> 21 <ec:InclusiveNamespaces 22 xmlns:ec="http://www.w3.org/2001/10/xmlexc-c14n#" 23 PrefixList="xsd" /> 24 </ds:Transform> 25 </ds:Transforms> 26 <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 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="https://saml20.caf.eauth.enspier.net:443/ID" 49 SPNameQualifier="https://saml20.caf.eauth.enspier.net:443/SP"> 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="https://sp.relyingparty1.com:443/amserver/Consumer/metaAlias/sp" /> 57 </saml:SubjectConfirmation> 58 </saml:Subject> 59 <saml:Conditions> 60 <saml:AudienceRestriction> 61 <saml:Audience>https://saml20.caf.eauth.enspier.net:443/SP</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> 73 https://saml20-07.caf.eauth.enspier.net:443/tfs/SAML20PasswordProtectedTransportStatement.xml 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 "1.7.3.4.1 Required Attributes" dictates three mandotory attributes:
- us:gov:e-authentication:basic:assuranceLevel
- urn:oid:2.5.4.3
- 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:
( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{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 "1.7.3.4.1 Required Attributes" nor in section "1.7.3.4.2 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.
0 comments :
Post a Comment