A-Use-Case-for-SAML-Extensibility by akgame

VIEWS: 24 PAGES: 28

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

								
To top