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

A Use Case for SAML Extensibility

Ashish Patel, France TelecomPaul 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 Introduction2) SAML Extensibility Mechanisms3) 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

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<complexType name="StatementAbstractType" abstract="true"/>

.<complexType name="AuthnStatementType"> <complexContent> <extension base="saml:StatementAbstractType"> <sequence> <element ref="saml:SubjectLocality" minOccurs="0"/> <element ref="saml:AuthnContext"/> </sequence> </extension> </complexContent></complexType>

Wildcards● Some content models contain the XSD

<xs:any>,<xs:anyAttribute> and <saml:Extensions> 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<complexType name="StatusResponseType"> <sequence> <element ref="saml:Issuer" minOccurs="0"/> <element ref="samlp:Extensions" minOccurs="0"/> <element ref="samlp:Status"/> </sequence> <attribute name="ID" type="ID" use="required"/> <attribute name="InResponseTo" type="NCName"/> <attribute name="Consent" type="anyURI"/></complexType><complexType name="ExtensionsType"> <sequence> <any namespace="##other" processContents="lax"/> </sequence></complexType>

Example Wildcard instance

<saml:Response ID=”” InResponseTo=”” Consent=””> <saml:Issuer>provider.example.com</saml:Issuer> <saml:Extensions> <other:OtherElement> </other:OtherElement> </saml:Extensions> <saml:Status> <saml:StatusCode Value=”Success”/> </saml:Status></saml:Response>

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<complexType name="NameIDType"> <simpleContent> <extension base="string"> <attributeGroup ref="saml:IDNameQualifiers"/> <attribute name="Format" type="anyURI" use="optional"/> <attribute name="SPProvidedID" type="string" use="optional"/> </extension> </simpleContent></complexType>

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 <Conditions> 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 3rd 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 - Requirements1) 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<samlp:AuthnRequest>. <samlp:Extensions>

<rac:RequestedAuthnContexts> <rac:AuthnContextClassRef> ac:classes:Password </rac:AuthnContextClassRef> <rac:AuthnContextClassRef> ac:classes:NonShared </rac:AuthnContextClassRef> </rac:RequestedAuthnContexts>

</samlp:Extensions>

</samlp:AuthnRequest>

Metadata Extension Example

<md:EntityDescriptor xmlns:md="SAML:2.0:metadata">

<md:SingleSignOnService

sc:supportsRequestedAC="true" .... />

</md:EntityDescriptor>

AC Declaration Extension Example <saml:AuthnContext>

<ac:AuthnContextDeclaration>

<ac:AuthnMethod>

<ac:PrincipalAuthenticationMechanism>

<ac:Extension>

<sc:SharedCredential>

true

</sc:SharedCredential>

</ac:Extension>

</ac:PrincipalAuthenticationMechanism>

</ac:AuthnMethod>

</ac:AuthnContextDeclaration>

</saml:AuthnContext>

Summary

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