SAML 2.0: Federation Models, Use-Cases and Standards Roadmap

1
SAML 2.0 Federation Models, Use-Cases and
Standards Roadmap

• Prateek MishraPrincipal identity
• Co-Chair, OASIS SSTC (SAML Committee)

2
Agenda

• SAML 2.0 Overview
• SAML 2.0 Feature Set
• Conclusions

3
SAML 2.0 Overview

• Charter and Timelines
• Standards Family Tree
• Normative Specification Set
• Specification Actors and Topics

4
Charter and Timelines

• Charter adopted by the SSTC
• ENHANCE Address issues and enhancement
  requests that have arisen from experience with
  real-world SAML implementations and with other
  security architectures that use SAML.
• REVISIT Add support for features that were
  deferred from previous versions of SAML.
• UNIFY Develop an approach for unifying various
  identity federation models found in real-world
  SAML implementations and SAML-based security
  architectures.
• Timelines
• First F2F meeting in September 2003
• Liberty ID-FF 1.2 submitted in November 2003 by
  Liberty Alliance
• SSTC declares specification to be a committee
  draft (CD) in August 2004
• Anticipate OASIS standardization during Q4/2004

5
Standards History
LA Liberty Alliance ID-FF
Identity Federation Framework
SAML Security Assertion Markup
LanguageXACML Extensible Access Control Markup
Language
Formally submitted to the SSTC
SAML 2.0Q4/2004?
ID-FF 1.2October 2003
LA 1.1January 2003
XACML 2.0Q4/2004?
Shibboleth1H03
SAML 1.1May 2003
WSS SAML Token Profile Q4/04
WSS SOAP Security Q4/03
SAML 1.0May 2002
XACML1.0February 2003
6
Normative Specification Set

• Conformance Requirements for the OASIS SAML V2.0
• Entry point for entire specification set
• Assertions and Protocols for the OASIS SAML V2.0
• SAML assertions schema SAMLAssn-xsd
• SAML protocols schema SAMLProt-xsd
• Bindings for the OASIS SAML V2.0
• Profiles for the OASIS SAML V2.0
• Metadata for the OASIS SAML V2.0
• SAML metadata schema SAMLMeta-xsd
• Authentication Context for the OASIS SAML V2.0
• Various authentication context schema files
• Security and Privacy Considerations for the OASIS
  SAML V2.0
• Glossary for the OASIS SAML V2.0

7
Specification Actors and Topics
UserClients
UserClients
IdentityProvider Session AuthorityAttributePr
ovider
Service ProviderSessionParticipant Attribute
Consumer
Metadata
IdentityFederation
SessionMngmt
AttributeServices
SSO
Trust Relationship
AttributeProvider
AttributeConsumer
Specification Topics
Actors
Actors
8
Agenda

• SAML 2.0 Overview
• SAML 2.0 Feature Set
• Federation Models in SAML 2.0
• Conclusion

9
SAML 2.0 Feature Set

• SSO
• Identity Federation
• Sessions and Logout
• Attribute Services
• Metadata

10
Single-Sign On

• Browser-driven SSO
• Form POST, SAML Artifact Profiles
• Note conformant implementations must implement
  both profiles
• Assertions may contain attribute statements
• SAML 2.0 introduces notion of attribute profile
• All or certain parts of an assertion may be
  encrypted
• Important when security intermediaries are
  involved
• SSO for enhanced client
• Enhanced client is a device that understands HTTP
  but not SOAP
• Also has built in knowledge of identity
  provider
• Examples
• HTTP proxies such as a WAP gateway
• Consumer device with HTTP client

11
SAML 2.0 Feature Set

• SSO
• Identity Federation
• What is (SAML 2.0) identity federation?
• Well known name or attribute
• Anonymous user Identified by attributes or roles
• User identified by privacy-preserving identifier
• Affiliations
• Managing and updating identity federations
• Privacy and user Consent
• Sessions and Logout
• Attribute Services
• Metadata

12
What is identity federation?

• Agreement between an identity provider and one or
  more service providers concerning the data using
  which users will be described
• By their e-mail address?
• By their office number and employee Id?
• By their role or membership in certain groups?
• By a unique (privacy preserving) identifier known
  only to the IdP and SP?
• Agreement creation may be accomplished in
  different ways
• Business agreements between IdP and SPs
• In some cases may require bulk update or
  synchronization of parts of the user store at
  both ends

13
Well known name or attribute

• SAML 2.0 supports the use of
• Email Address
• X.509 Subject Name
• Windows Domain Qualified Name
• Kerberos Principal Name
• Attribute (e.g., employee number)
• User entry at the IdP and SP(s) are keyed off the
  name or attribute
• Privacy preservation is not an issue here
• Names may be encrypted to protect against
  intermediaries
• Common use-case in many SAML 1.X deployments

14
Anonymous user with attributes or roles

• User is never explicitly identified by a
  persistent identifier
• A transient identifier is used as the name of
  the user
• One or more roles or attributes describe the user
• EmploymentLevel Manager
• AccessRights Platinum
• MemberOf BellRingers
• Access at Service Provider is given against roles
  or attributes
• No need to maintain user entry at SP
• Privacy Preserving as user identity at IdP
  remains unknown
• Main use case in Shibboleth and some SAML 1.X
  deployments

15
User identified by privacy-preserving identifier

• User is identified by a persistent randomized
  string private to IdP and SP pairs
• Unique handle per service provider
• Privacy-preserving since no information about
  user is available at SP
• Requires IdP and SP to synchronize portions of
  their user stores
• Affiliations important sub-case where a single
  persistent randomized string is shared between a
  set of Service Providers
• Main use case in ID-FF 1.X specifications and
  deployments

16
Name Identifier Management

• Protocol for communicating information about name
  identifiers
• When identifiers should be updated
• Replace jsmith_at_foo.com by johns_at_foo.com
• Rollover privacy preserving identifier at SP
  every 6 months
• Update identifier at IdP with identifier
  meaningful to SP
• When an identifier will no longer be acceptable
  for federation
• IdP will not issue any more assertions for
  jsmith_at_foo.com
• SP will not accept assertions for jsmith_at_foo.com

17
Privacy and User Consent

• Privacy
• SAML 2.0 includes recommendations for privacy
  preservation if and when desired
• Main idea is that Identity providers need not
  release any personal information about users to
  service providers
• User Consent
• SSO protocol includes ability to query and record
  user-consent
• Identity providers and service providers can
  choose to provide services based on whether
  user-consent was obtained and recorded

18
SAML 2.0 Feature Set

• Overview
• SSO
• Identity Federation
• Sessions and Logout
• Attribute Services
• Metadata

19
Sessions and Logout

• Identity providers as session authorities,
  service providers as session participants
• Identity providers provide session identifier(s)
  to service providers
• User may logout at IdP or SP to terminate session
  
• Ability to terminate all or some sessions of a
  user
• Solution follows ID-FF 1.2 closely (logout but no
  timeout) but also provides extension points for
  richer session models
• Instructions for privacy preservation are
  provided
• Multiple service providers should not be able to
  collude and determine if it is the same user
  who is participating in a shared session

20
Attribute Services

• Support for attribute names and values drawn from
  a variety of syntaxes
• Basic Attribute Profile string names and
  attribute values drawn from XML schema primitive
  type definitions
• X.500/LDAP Attribute Profile use of canonical
  X.500/LDAP attribute names and values
• UUID Attribute Profile Use of UUIDs as attribute
  names
• XACML Attribute Profile formats suitable for
  processing by XACML
• Attributes statements may be transferred during
  SSO or by the use of the AttributeQuery protocol
• Attributes may be encrypted to ensure end-to-end
  confidentiality

21
Metadata

• Identifies the distinct roles or actors involved
  in profiles
• SSO Identity Provider
• SSO Service Provider
• Attribute Authority
• Attribute Requester
• Specifies data that must be agreed upon between
  system entities regarding identifiers, supported
  profiles, URLs, certificates and keys
• Configuration data
• Trust data
• Will aid improved deployability of SAML components

22
Agenda

• Federation Preliminaries
• Federation Agreements in SAML 2.0
• Conclusion

23
Conclusion

• SAML 2.0 integrates deployment experience from
  SAML 1.1 and Shibboleth, and new protocols from
  ID-FF 1.2 into a single standard
• Supports flexible identity federation models
  corresponding to different business use-cases
• Provides a complete solution for identity
  federation for web applications with no missing
  last mile pieces