1 saml 2.0: federation models, use-cases and standards roadmap prateek mishra principal identity...
TRANSCRIPT
1
SAML 2.0: Federation Models, Use-Cases and
Standards Roadmap
Prateek Mishra
Principal identityCo-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
SAML 1.0May 2002
SAML 1.1May 2003
LA 1.1January 2003
ID-FF 1.2October 2003
LA: Liberty Alliance ID-FF: Identity Federation Framework SAML: Security Assertion Markup LanguageXACML: Extensible Access Control Markup Language
Shibboleth1H03
XACML1.0February 2003
WSS SAML Token Profile Q4/04
Formally submitted to the SSTC
SAML 2.0Q4/2004?
XACML 2.0Q4/2004?
WSS SOAP Security Q4/03
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
IdentityProvider
Session Authority
AttributeProvider
Service Provider
SessionParticipant
Attribute Consumer
Trust RelationshipAttributeProvider
IdentityFederation
SessionMngmt
AttributeServices
AttributeConsumer
Metadata
Actors Actors
UserClients
UserClients
Specification Topics
SSO
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 SP’s 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 [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]
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