SAML 2.0 Overview - OASIS Mailing List Directory

SAML 2.0 Overview - OASIS Mailing List Directory

SAML 2.0: Federation
Models, Use-Cases and
Standards Roadmap
Prateek Mishra
Principal identity
Co-Chair, OASIS SSTC
(SAML Committee)
1
Agenda



SAML 2.0 Overview
SAML 2.0 Feature Set
Conclusions
2
SAML 2.0 Overview




Charter and Timelines
Standards Family Tree
Normative Specification Set
Specification Actors and Topics
3
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
4
Standards History
LA: Liberty Alliance
ID-FF: Identity Federation Framework
SAML: Security Assertion Markup Language
XACML: Extensible Access Control Markup Language
Formally submitted to the SSTC
ID-FF 1.2
October 2003
LA 1.1
January 2003
Shibboleth
1H03
SAML 1.1
May 2003
SAML 1.0
May 2002
SAML 2.0
Q4/2004?
WSS SOAP
Security Q4/03
XACML 2.0
Q4/2004?
WSS SAML Token
Profile Q4/04
XACML1.0
February 2003
5
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
6
Specification Actors and Topics
User
Clients
User
Clients
Identity
Provider
Service
Provider
Session
Authority
Attribute
Provider
Attribute
Provider
Actors
Session
Participant
Metadata
SSO
Identity
Federation
Session
Mngmt
Trust Relationship
Specification Topics
Attribute
Services
Attribute
Consumer
Attribute
Consumer
Actors
7
Agenda




SAML 2.0 Overview
SAML 2.0 Feature Set
Federation Models in SAML 2.0
Conclusion
8
SAML 2.0 Feature Set





SSO
Identity Federation
Sessions and Logout
Attribute Services
Metadata
9
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
10
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
11
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 SP’s
 In some cases may require bulk update or synchronization of
parts of the user store at both ends
12
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
13
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
14
User identified by privacypreserving 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
15
Name Identifier Management

Protocol for communicating information about name identifiers
 When identifiers should be updated
 Replace [email protected] by [email protected]
 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
[email protected]
 SP will not accept assertions for [email protected]
16
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 userconsent was obtained and recorded
17
SAML 2.0 Feature Set






Overview
SSO
Identity Federation
Sessions and Logout
Attribute Services
Metadata
18
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
19
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
20
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
21
Agenda



Federation Preliminaries
Federation Agreements in SAML 2.0
Conclusion
22
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
23