A Use Case for SAML Extensibility Ashish Patel, France Telecom Paul Madsen, NTT

Overview ● Interoperability is best enabled by tightly defined specifications. ● But, new requirements, unforeseen when specs are first defined, will inevitably emerge. ● An extensible standard provides near-term interoperability while accounting for such future requirements. ● Designers of SAML attempted to anticipate future requirements by building in extensibility points throughout specifications. ● We'll discuss the application of SAML's extensibility mechanisms in meeting the requirements of a common ISP identity use case.

Agenda 1) SAML Introduction 2) SAML Extensibility Mechanisms 3) Extensibility Use Case – 'Shared Credentials' 4) Summary

SAML Introduction (Brief)

SAML Introduction ● Security Assertions Markup Language (SAML) defines XML-based protocols & syntax for passing security & identity attributes between providers ● SAML 2.0 standardized by OASIS Security Services TC in Mar 2005 ● Defines assertion & protocol syntax, bindings to transport channels, and profiles for typical applications ● Strong support across wide range of applications & industry, including telecommunications

SAML Extensibility Mechanisms

● Extensibility of structure – includes ways to modify (add to or subtract from) SAML's native XML content models. ● Extensibility of protocol – includes ways to define new flows, called profiles, of SAML assertion creation, usage, and exchange. Sometimes these profiles also involve extended XML structures and content, as described above. Extensibility of content - includes ways to customize the format and interpretation of the content of SAML's XML elements and attributes.

Derived Types ● XML Schema allows a type to serve as a base type of an extended (or restricted) type ● All of SAML's defined types are non-final and are explicitly documented as being derivable. ● SAML defines “deep” complex type hierarchies (and matching elements) especially for derivation purposes. ● Such “Abstract” types MUST be derived and cannot appear directly in a SAML instance ● Allows for definition of completely novel assertion types

Example type extension point. <element ref="saml:SubjectLocality" minOccurs="0"/>

Wildcards ● Some content models contain the XSD, and structures. ● They create partially or fully “open” portions of a content model, where a variety of specific elements not foreseen by the original schema may appear. ● Allows elements from different namespaces to appear in assertions and protocols ● Such extensions can go unremarked – no need for new types to be defined

Example wildcard extension point

Example Wildcard instance provider.example.com

URI Identifiers ● SAML uses URI-based identifiers for interpreting selected SAML element and attribute content correctly. ● Different meanings indicated through an attribute that contains a URI reference ● Extensible through the definition of new URI values. ● Technique specific to the SAML vocabulary and not global to XSD.

Example URI extension point <attribute name="Format" type="anyURI" use="optional"/> <attribute name="SPProvidedID" type="string" use="optional"/>

Successful Extensions of SAML ● Liberty ID-FF is best known example of a customization/extension of SAML 1.0/1.1 – ID-FF used derived types to extend SAML AuthnRequest & AuthnResponse ● Shibboleth defined new URIs for Format and AttributeNamespace. ● XACML uses derived types to extend the SAML base request type for its own authz & policy queries ● SIP uses the extension point for binding a SAML 1.1 assertion to a SIP message

Extensibility Use Case - “Shared Credentials”

Shared Credentials Use case ISPs and Telcos often identify "family" of Principals via IP address or phone line circuit. This passive authentication is sufficient to grant access to certain services: placing a phone call, accessing internet. Also need to be able to deliver personalized service to such shared terminals. A 3 rd party service provider may provide both group level and personalized service e.g. address book in the above mentioned setup. The SP relies on the IDP for both passive group authentication as well as active individual level authentication.

Shared Credentials - Use case Cont'd

Shared Credentials - Requirements 1) The SP can rely on IDP to authenticate Principal at both group and individual level. 2) The IDP can specify type of assertion it is issuing i.e. whether Principal was authenticated at group or individual level. 3) The SP can request of the IDP a particular type of assertion (group/individual). 4) The SP may not have knowledge about Principal belonging to group.

Shared Credentials - Proposal Group or individual level will be distinguished by the type of credential by which the user authenticates to the IDP. Group Identity == Shared Credential Nature of the credential (i.e. shared or unique) will be expressed through the SAML Authentication Context (AC) framework SAML AC provides a syntax by which the context of an authentication event can be expressed. Shared credential interpreted as just another aspect of the authentication context.

Shared Credentials - Details Current request structure give SP little flexibility in expressing combinations of AC requirements 1) We are proposing a new protocol extension to provide the required flexibility 2) We are proposing a new metadata extension by which providers can advertise support above extensions. Current AC language does not cover concept of shared credentials 3) We are proposing a new AC schema extension to distinguish between shared /unique credentials

Protocol Extension Example. ac:classes:Password ac:classes:NonShared

Metadata Extension Example <md:EntityDescriptor xmlns:md="SAML:2.0:metadata"> <md:SingleSignOnService sc:supportsRequestedAC="true".... />

AC Declaration Extension Example true

Summary

SAML 2.0 provides a number of extensibility points by which new requirements, unforeseen at original drafting, can be accomodated in an interoperable manner. We are proposing to leverage a number of SAML's extensibility points in order to address our Shared Credential Use Case requirements. Balancing support for new Shared Credential requirements with interoperability based on unextended SAML 2.0 specs

'We demand rigidly defined areas of doubt and uncertainty' Vroomfondle in Hitchhiker's Guide to the Galaxy

Thank You