Embed Size (px)
Citation preview
Outline
• Parameters of some issues facing us in development of XSD-compliant schemas– CONS-04– CONS-03– A small selection of others
• My recommendations
• TC discussion/decisions
Issue CONS-04: Extensibility of assertions
Our putative requirements for assertions
1. Factor out commonalities and package them in a way that can be leveraged by SAML processors
2. Allow users to define (a) extensions to native SAML assertions and (b) novel assertion types
3. Ensure that both native and user-defined assertions can appear in all the right places
#1: Factoring out commonalities
Currently done with complex types
• AssertionAbstractType– SubjectAssertionAbstractType
• AuthenticationAssertionType• AuthorizationDecisionAssertionType• AttributeAssertionType
• Example instance:
<saml:Assertion xsi:type=“AttributeAssertionType”>…</saml:Assertion>
Does it meet the requirement?
• Yes, because XSD types are nominally accessible to software– Even if the PSVI isn’t truly accessible yet, data
binding is heavily used
• Model groups are the only other choice– But being macro-like, they nominally aren’t
accessible to software
• So no issue here
#2: User-defined extensionsand novel kinds of assertions
Currently done with non-final complex types
• AssertionAbstractType– SubjectAssertionAbstractType
• AuthenticationAssertionType– User-defined extensions of AuthN-type assertions
• AuthorizationDecisionAssertionType– User-defined extensions of AuthZDecision-type assertions
• AttributeAssertionType– User-defined extensions of Attrib-type assertions
• Novel user-defined extensions with subject info
– Novel user-defined extensions
Examples
<saml:Assertion xsi:type=“AttributeAssertionType”> (Attrib-specific stuff goes here)</Assertion>
<saml:Assertion xsi:type=“MyAttributeAssertionType”> (Attrib-specific stuff goes here, plus my stuff tacked on to the end)</Assertion>
<saml:Assertion xsi:type=“MyOtherAttributeAssertionType”> (Attrib-specific stuff goes here, with tighter occurrence constraints)</Assertion>
Does it meet the requirement?
• Yes; users can create extensions and restrictions by declaring derived types
• Derived-type elements must use the xsi:type attribute and element name is always <Assertion>– But this is true of native elements as well…
Another option for part of the problem
• We could use <any> wildcards in content models to give extensibility without subtyping
• Gives finer control over position, number, and namespace of foreign elements
• Type derivation is still needed for totally novel assertion types
Example: extensible attribute assertions without new types
<xsd:complexType name=“AttributeAssertionType”> <xsd:complexContent> <xsd:extension base=“saml:SubjectAssertionAbstractType”> <xsd:sequence> <xsd:any namespace=“##any” maxOccurs=“1”/> <xsd:element ref=“saml:Attribute” maxOccurs=“unbounded”/> <xsd:any namespace=“##other” maxOccurs=“unbounded”/> </xsd:sequence> </xsd:extension> </xsd:complexContent></xsd:complexType>
Example: instance of extended attribute assertion
<saml:Assertion xsi:type=“AttributeAssertionType”> <saml:Subject>…</saml:Subject> <saml:DNS_Domain>…</saml:DNS_Domain> <saml:Attribute>…</saml:Attribute> <xhtml:p>…</xhtml:p> <xhtml:ul>…</xhtml:ul></saml:Assertion>
#3: Allowing all kinds of assertions to appear in all the
right places
Currently done with reference to <Assertion> element
• Assertions may appear in <AssertionSpecifier> and <Response>
• A plain <Assertion> can’t be used– Its type is abstract
• It requires an xsi:type attribute to nail down the concrete type used
Examples, again
<saml:Assertion xsi:type=“AttributeAssertionType”> (Attribute stuff goes here)</Assertion>
<saml:Assertion xsi:type=“MyAttributeAssertionType”> (Attribute stuff goes here, plus my stuff tacked on to the end)</Assertion>
<saml:Assertion xsi:type=“MyOtherAttributeAssertionType”> (Attribute stuff goes here, with tighter occurrence constraints)</Assertion>
Does it meet the requirement?
• Yes, because all descendants from AssertionAbstractType can go in those two spots
• Some consequences:– Processors must examine the xsi:type attribute
in all cases– Native and user-defined assertions look alike
Another option: substitution groups
• It works by declaring elements to be substitutable for a “head element”
• Because this gets done on an element declaration, and elements must have types, xsi:type isn’t needed in instances
• All substitutable elements must have the same type as the head element (or a derived one)
Example: native SAML elements substitutable for <Assertion>
<xsd:element name=“AuthenticationAssertion” type=“AuthenticationAssertionType” substitutionGroup=“saml:Assertion”/>
<xsd:element name=“AttributeAssertion” type=“AttributeAssertionType” substitutionGroup=“saml:Assertion”/>
<xsd:element name=“AuthorizationDecisionAssertion” type=“AuthorizationDecisionAssertionType” substitutionGroup=“saml:Assertion”/>
Example: native SAML assertion elements in an instance
<saml:AuthenticationAssertion> (Authentication stuff goes here)</saml:AuthenticationAssertion>
<saml:AttributeAssertion> (Attribute stuff goes here)</saml:AttributeAssertion>
<saml:AuthorizationDecisionAssertion> (Authorization decision stuff goes here)</saml:AuthorizationDecisionAssertion>
Interaction of type derivation and substitution groups
• They can be mixed together freely (by default)• If the SAML assertion schema relies on type
derivation (as it does today), extension schemas could still define new substitutable elements with <Assertion> as a head element
• If the SAML assertion schema is changed to use substitution groups, extension schemas could still define new types and use xsi:type
Examples: user-defined assertions done two ways
(new type derived from subject assertions; can be used directly in instance if xsi:type is used)<xsd:complexType name=“SessionAssertion”> <xsd:complexContent> <xsd:extension base=“saml:SubjectAssertionAbstractType”> … </xsd:extension> </xsd:complexContent></xsd:complexType>
(add this to schema to use new element as substitute for <Assertion> element without using xsi:type)<xsd:element name=“SessionAssertion” type=“SessionAssertionType” substitutionGroup=“saml:Assertion”/>
Yet another option: model groups
• Not considering this option seriously
• Model groups are macro-like and thus remove all certainty about type adherence
• They would require user-defined schemas to use the redefine mechanism
Issue CONS-03: Subtyping in general
Currently all types are implicitly set non-final
• Any type can be used as the basis for derivation, not just assertion-related types
• Any user can extend or restrict our constraints (according to XSD’s abilities)
Example: extending the NameIdentifierType type
<xsd:complexType name=“MyNameIdentifierType”> <xsd:complexContent> <xsd:extension base=“NameIdentifierType”> <xsd:sequence> (after <SecurityDomain> and <Name> comes my new stuff) <xsd:element name=“MyHooHaa” …/> </xsd:sequence> <xsd:extension> <xsd:/complexContent></xsd:complexType>
What is the requirement?
• Flexibility makes sense for:– Our own experimentation for future versions– Innovation by users
• But there are interoperability risks if we allow redefinition of SAML semantics through addition of “foreign matter”
• The XSLT spec mitigates this with prose
Issue: global vs. local element declarations
Currently there is a mix of both
• E.g., <Conditions> is defined both as:– Local to elements of AssertionAbstractType– Local to elements of AttributeValueType
• They happen to have the same definition, but they needn’t
• The pattern of global vs. local is unclear• How do local elements get processed, particularly
if they have different types?– E.g., how does XSLT distinguish them? Is xsi:type
required?
Recommendations and discussion
Major questions raised here
1. Should substitution groups be used in the SAML assertion schema instead of the xsi:type framework for extension?
2. Should <any> wildcards be used to allow extensibility in the three assertion types?
3. Should we set a restrictive finalDefault for the schema as a whole to close off extensions?
4. Should we use global element definitions exclusively rather than a mix?
YES on #1: Substitution groups instead of xsi:type in our schema
• Attribute processing is more expensive than element processing; substitution groups eliminate xsi:type from “pure SAML” schemas
• Extensions to native assertions can enable smarter processing even when the derived type is unfamiliar
<saml:AttributeAssertion type=“MyAttributeAssertionType”>…</saml:AttributeAssertion>
• DocBook role and HTML class provide philosophical precedents
NO on #2: <any> wildcards for type extension
• The <any> option allows extensions to go “unremarked”; with derived types, extension schemas clearly define their own types and elements
• This way, we don’t have to do the design work of figuring out where/how to place the <any>s
• We seem to have no particular need for tight control of extensions beyond what XSD extensions offer
NO on #3: Restrictive finalDefault for the schema
• Why cut off our (or our users’) options? Isn’t this what XML Schema is good at?
• But we have to make sure that we disallow proprietary game-playing in our conformance language
YES on #4: Universal use of global elements
• XML standards and tools are not savvy enough yet to handle local elements “natively”
• Those who clamored for this feature had huge DTDs with many subelements, where there were similar but not identical names and characteristics for each “branch”– We don’t have this problem
