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 jsmith@foo.com by johns@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@foo.com SP will not accept assertions for jsmith@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