1 / 28

A Use Case for SAML Extensibility

Ashish Patel, France Telecom Paul Madsen, NTT. A Use Case for SAML Extensibility. Overview. Interoperability is best enabled by tightly defined specifications. But, new requirements, unforeseen when specs are first defined, will inevitably emerge.

orea
Download Presentation

A Use Case for SAML Extensibility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

  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 <Conditions> 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 <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>

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

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

  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

More Related