OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: SAML 2 AuthnContext Schema Problems


We have been working with the current drafts of the SAML 2 schemas and have found numerous schema validity problems in the Authentication Context areas.

In all these cases, the pattern falls along the lines of the following example:

(from sstc-saml-schema-authn-context-2.0.xsd:)

  <xs:complexType name="PasswordType">
    <xs:sequence>
      <xs:element ref="Length" minOccurs="0"/>
      <xs:element ref="Alphabet" minOccurs="0"/>
      <xs:element ref="Generation" minOccurs="0"/>
      <xs:element ref="Extension" minOccurs="0"
        maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="ExternalVerification" type="xs:anyURI" use="optional"/>
  </xs:complexType>

  <xs:element name="RestrictedPassword" type="RestrictedPasswordType"/>

  <xs:complexType name="RestrictedPasswordType">
    <xs:complexContent>
      <xs:restriction base="PasswordType">
        <xs:sequence>
          <xs:element ref="RestrictedLength" minOccurs="1"/>
          <xs:element ref="Generation" minOccurs="0"/>
          <xs:element ref="Extension" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="ExternalVerification" type="xs:anyURI" use="optional"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  
Above, we see the PasswordType being defined normally, and then RestrictedPasswordType being defined as a restricted version of PasswordType. That's cool so far, but the problem is, the new attribute "RestrictedLength" is being surreptitiously introduced within the <restriction> block. This is not allowed -- a restriction block can only contain a subset of the elements in the base type, and cannot introduce new ones.

As a workaround, we modified the schema to break this up into two steps using an intermediate type - first, restrict PasswordType into a restricted intermediary (which we called sidPasswordType but you can name it anything you like). Then, extend the intermediate type with the new element (RestrictedLength).

Like so:

  <xs:complexType name="PasswordType">
    <xs:sequence>
      <xs:element ref="Length" minOccurs="0"/>
      <xs:element ref="Alphabet" minOccurs="0"/>
      <xs:element ref="Generation" minOccurs="0"/>
      <xs:element ref="Extension" minOccurs="0"
        maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="ExternalVerification" type="xs:anyURI" use="optional"/>
  </xs:complexType>

  <xs:element name="sidRestrictedPassword" type="sidRestrictedPasswordType"/>

  <xs:complexType name="sidRestrictedPasswordType">
    <xs:complexContent>
      <xs:restriction base="PasswordType">
        <xs:sequence>
          <xs:element ref="Generation" minOccurs="0"/>
          <xs:element ref="Extension" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="ExternalVerification" type="xs:anyURI" use="optional"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
 
  <xs:element name="RestrictedPassword" type="RestrictedPasswordType"/>

  <xs:complexType name="RestrictedPasswordType">
    <xs:complexContent>
      <xs:extension base="sidRestrictedPasswordType">
        <xs:sequence>
          <xs:element ref="RestrictedLength" minOccurs="1"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


A good, strict schema validator will catch these problems and help sort them out (as we did). We recommend these schemas be fixed in this regard for the next draft iteration.

Thank you,

Bryan Field-Elliot
Ping Identity Corporation





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]