A Use Case for SAML Extensibility

1
A Use Case for SAML Extensibility

• Ashish Patel, France Telecom
• Paul Madsen, NTT

2
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.

3
Agenda

• SAML Introduction
• SAML Extensibility Mechanisms
• Extensibility Use Case 'Shared Credentials'
• Summary

4
SAML Introduction (Brief)
5
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

6
SAML Extensibility Mechanisms
7
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.

8
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

9
Example type extension point

• ltcomplexType name"StatementAbstractType"
  abstract"true"/gt
• .
• ltcomplexType name"AuthnStatementType"gt
• ltcomplexContentgt
• ltextension base"samlStatementAbstractType"gt
• ltsequencegt
• ltelement ref"samlSubjectLocality"
• minOccurs"0"/gt
• ltelement ref"samlAuthnContext"/gt
• lt/sequencegt
• lt/extensiongt
• lt/complexContentgt
• lt/complexTypegt

10
Wildcards

• Some content models contain the XSD
  ltxsanygt,ltxsanyAttributegt and ltsamlExtensionsgt
  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

11
Example wildcard extension point

• ltcomplexType name"StatusResponseType"gt
• ltsequencegt
• ltelement ref"samlIssuer" minOccurs"0"/gt
• ltelement ref"samlpExtensions"
  minOccurs"0"/gt
• ltelement ref"samlpStatus"/gt
• lt/sequencegt
• ltattribute name"ID" type"ID"
  use"required"/gt
• ltattribute name"InResponseTo"
  type"NCName"/gt
• ltattribute name"Consent" type"anyURI"/gt
• lt/complexTypegt
• ltcomplexType name"ExtensionsType"gt
• ltsequencegt
• ltany namespace"other" processContents"lax
  "/gt
• lt/sequencegt
• lt/complexTypegt

12
Example Wildcard instance

• ltsamlResponse ID InResponseTo Consentgt
• ltsamlIssuergtprovider.example.comlt/samlIssuergt
• ltsamlExtensionsgt
• ltotherOtherElementgt
• lt/otherOtherElementgt
• lt/samlExtensionsgt
• ltsamlStatusgt
• ltsamlStatusCode ValueSuccess/gt
• lt/samlStatusgt
• lt/samlResponsegt

13
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.

14
Example URI extension point

• ltcomplexType name"NameIDType"gt
• ltsimpleContentgt
• ltextension base"string"gt
• ltattributeGroup ref"samlIDNameQualifiers"/gt
• ltattribute name"Format" type"anyURI"
• use"optional"/gt
• ltattribute name"SPProvidedID" type"string"
• use"optional"/gt
• lt/extensiongt
• lt/simpleContentgt
• lt/complexTypegt

15
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 ltConditionsgt extension point for
  binding a SAML 1.1 assertion to a SIP message

16
Extensibility Use Case - Shared Credentials
17
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.

18
Shared Credentials - Use case Cont'd
19
Shared Credentials - Requirements

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

20
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.

21
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

22
Protocol Extension Example

• ltsamlpAuthnRequestgt
• .
• ltsamlpExtensionsgt
• ltracRequestedAuthnContextsgt
• ltracAuthnContextClassRefgt
• acclassesPassword
• lt/racAuthnContextClassRefgt
• ltracAuthnContextClassRefgt
• acclassesNonShared
• lt/racAuthnContextClassRefgt
• lt/racRequestedAuthnContextsgt
• lt/samlpExtensionsgt
• lt/samlpAuthnRequestgt

23
Metadata Extension Example

• ltmdEntityDescriptor
• xmlnsmd"SAML2.0metadata"gt
• ltmdSingleSignOnService
• scsupportsRequestedAC"true" .... /gt
• lt/mdEntityDescriptorgt

24
AC Declaration Extension Example

• ltsamlAuthnContextgt
• ltacAuthnContextDeclarationgt
• ltacAuthnMethodgt
• ltacPrincipalAuthenticationMechanismgt
• ltacExtensiongt
• ltscSharedCredentialgt
  
• true
• lt/scSharedCredentialgt
• lt/acExtensiongt
• lt/acPrincipalAuthenticationMechanismgt
  
• lt/acAuthnMethodgt
• lt/acAuthnContextDeclarationgt
• lt/samlAuthnContextgt

25
Summary
26
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

27

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

28
Thank You