Federating Technologies:SAML, Shibboleth,

and the Field

Scott Cantor

cantor.2@osu.edu

The Ohio State University

Internet2/MACE© Scott Cantor 2006. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

Outline

Introductions

Federated Identity

SAML

Shibboleth

Liberty Alliance

Other Activities

Federated Identity Concepts

Loose Coupling

Technical Normalization

Glosses Internal/External Distinctions

Linkage over Storage

Identity Transformation

Focused on Interchange (XML)

OASIShttp://www.oasis-open.org/

Organization for the Advancement of Structured Information Standards

Founded in 1993 as a consortium of SGML vendors

Home for self-organizing committees chartered to develop particular technologies

Achieved greater visibility with buzzword-compliance of XML and web services

SAMLhttp://ww.oasis-open.org/committees/security

Security Assertion Markup Language

OASIS standard for exchanging security and identity-related information within and between security domains

In its second generation, and has stablized

Mature standard for web-based federation

Increasingly a basis of new work

SAML Use Case Exampleshttp://www.oasis-open.org/committees/download.php/507

Third-party (verified) authentication of clients to resources within or between security domains

Single sign-on of web browser to multiple sites within or between security domains

Attribute exchange Delegating authorization decisions Attachable signed "tokens" for application

messages

SAML Background / Timeline

Initial standardization effort began in OASIS in 2001 to unify specifications submitted by Netegrity and Securant. SAML 1.0 completed and approved Nov 2002.

Liberty Alliance ID-FF 1.1 forks off SAML 1.0

SAML 1.1 completed and approved Sept 2003.

Liberty Alliance ID-FF 1.2 forks off SAML 1.1

Liberty Alliance submits ID-FF to SSTC

SAML 2.0 completed and approved March 2005

Road to Convergence

ID-FF 1.1

SAML 1.0 SAML 1.1

Shibboleth 1.x

ID-FF 1.2

SAML 2.0

2002 2003 2004

SAML 1.0 (2002)Scope of Interoperability

Source-site initiated web authentication POST Profile

Artifact / Callback Profile

Attribute exchange protocol via SOAP

Authz query/decision protocol via SOAP

Free-standing assertion format *(*) relatively untested

SAML POST Profile

Source Site

ITS

(1)

(2)

1. HTTP Request (non-normative) to Intersite Transfer Service

2. Signed <samlp:Response> in HTML FORM (action=POST)

3. HTTP POST to Assertion Consumer Service

4. HTTP Response

Destination Site

ACS

(3)

(4)

SAML Artifact Profile

Source Site

ITS

(1)

(2)

1. HTTP Request (non-normative) to Intersite Transfer Service

2. HTTP Redirect with SAMLart Parameter

3. HTTP GET to Assertion Consumer Service with SAMLart Parameter

4. SAML SOAP Query / Response (authenticated exchange)

5. HTTP Response

Destination Site

ACS

(3)

(5)

(4)

Liberty ID-FF 1.0/1.1 (2002-2003)Scope of Interoperability

IdP/SP initiated web authentication

Account linking with IdP-managed pair-wise identifiers

Authentication context

Single logout protocol

Identifier refresh / revocation

Limited configuration metadata format

SAML 1.1 (2003)

Addressed XML signature interoperability (necessary for POST profile and effective use with web services)

Specification cleanup

Managed badly, resulting in backward-incompatibility

Shibboleth 1.x (2002-2004)Scope of Interoperability SAML 1.1 with a few additions

IdP/SP initiated web authentication

Anonymity and attribute-based access control

Account linking with SAML attributes

Limited configuration metadata format

Liberty ID-FF 1.2 (2004)Scope of Interoperability Evolution of ID-FF 1.1, rebased on SAML 1.1:

"One-time" user identifiers, similar to Shibboleth’s

Richer metadata exchange

Limited use of XML Encryption

First significant exploration of SAML as a web service security mechanism in ID-WSF 1.0

SAML 2.0 (2005) Vulcan mind-meld of SAML 1.1, Shibboleth

and Liberty ID-FF 1.2 approaches and profiles Challenges:

Incorporate ID-FF technical solutions into a generalized SAML framework

Manage increase in size of specification Maintain momentum, consistency Begin to support non-browser use cases in a

consistent fashion (including, but not limited to, web services)

Increased politicization

Refactored SAML 2.0 Specifications Conformance Assertions

SAML as security token or wrapper, common extensible base Protocols

Synchronous message exchange involving SAML assertions or in support of SAML use cases

Bindings Concrete SAML message exchange over a transport protocol

Profiles Basic unit of interoperability applying a protocol or assertion

capability Metadata Authentication Context

SAML Assertions An XML fragment binding “statements” about a

“subject”, issued by an “authority” to one or more relying parties: Issuer Subject

Identifier Confirmation

Statements Authentication, Attribute, Authorization Decision, etc.

Conditions Validity period, audiences, obligations

Advice

SAML 2.0 Example<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0“

ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2003-04-17T00:46:02Z">

<Issuer>https://www.opensaml.org/IDP"</Issuer>

<ds:Signature xmlns:ds="...">...</ds:Signature>

<Subject>

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">scott@example.org</NameID>

<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<SubjectConfirmationData NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2003-04-17T00:51:02Z"/>

</SubjectConfirmation>

</Subject>

<Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2003-04-17T01:46:02Z">

<AudienceRestriction>

<Audience>http://www.opensaml.org/SP</Audience>

</AudienceRestriction>

</Conditions>

<AuthnStatement AuthnInstant="2003-04-17T00:46:00Z">

<AuthnContext>

<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>

</AuthnContext>

</AuthnStatement>

</Assertion>

SAML Protocols Rudimentary schema types for request/response

protocol Designed to be transport (and SOAP)-independent Supports signed messages, correlation, replay

detection Derived into specific protocols

AuthnRequest/Response LogoutRequest/Response NameIDManageRequest/Response NameIDMappingRequest/Response Attribute-Authn-AuthzDecisionQuery/Response …

SAML Bindings Given a protocol message, defines:

encoding for transport security characteristics

Synchronous SOAP URI resolution of assertions

Asynchronous HTTP U-A bindings (Redirect, POST, Artifact) PAOS (Reverse SOAP)

SAML Profiles Browser and Enhanced Client Single Sign-

On

Single Logout

NameID Management

NameID Mapping

Query Profiles

Artifact Binding Resolution

Attribute Profiles

SAML 2.0 SSO Profile (e.g.)

Identity Provider

SSOS

(3)

(4)

1. HTTP Request (non-normative) to SP

2. <samlp:AuthnRequest> encoded in URL Redirect

3. <samlp:AuthnRequest> passed to SSO Service via HTTP GET

4. <samlp:Response> in HTML FORM (action=POST) containing signed <saml:Assertion>

5. HTTP POST to Assertion Consumer Service

6. HTTP Response

Service Provider

ACS

(5)(6)

(1)

(2)

SAML 2.0 Logout Profile (e.g.)

Identity Provider

SLOS

(3)

(4)

1. HTTP Request (non-normative) to SP

2. <samlp:LogoutRequest> encoded in URL Redirect

3. <samlp:LogoutRequest> passed to IdP SLO Service via HTTP GET

4. <samlp:LogoutResponse> encoded in URL Redirect

5. <samlp:LogoutResponse> passed to SP SLO Service via HTTP GET

6. HTTP Response

Service Provider

SLOS

(5)(6)

(1)

(2)

Emerging SAML Use Cases

Attribute exchange layered on X.509 authentication (e.g. GridShib)

SASL/GSS-API mechanism

SIP

Delegation / multi-tier scenarios

Status of Committee

OASIS doesn’t have a defined process for maintaining its specifications

Errata (non-normative?)

Additional profiles and extensions Metadata for SAML 1.x, unsupported use cases

Third-party generation of SAML requests

X.509 authentication with attribute sharing

Industry Support

Dozen or more commercial and open source SAML 1.x (and usually ID-FF 1.x) Web SSO products (software and hardware)

Microsoft ADFS uses SAML 1.1 assertions as security tokens

A few major COTS applications include SAML support, notably some ERP vendor portals

Most SAML/Liberty vendors have announced or shipped SAML 2.0 products

Latest WS-Security specs support SAML 2.0, as will Liberty ID-WSF 2.0

Shibboleth (Re)Defined Shibboleth Project

An umbrella of activities around federated authentication and access management managed by Internet2 and its international partners, still ad hoc but moving toward some formalism

Shibboleth SpecificationsThe wire protocols and conformance requirements that define

"Shibboleth Compatible", currently derived in large part from SAML 1.1

Shibboleth SystemInternet2-developed open source implementation of the

specifications plus value-added componentsNot the only extant or planned implementation (at least 2-3 other

implementations known, lots of smaller projects based on the code base)

Shibboleth (Re)(Re)DefinedShibboleth Project

An umbrella of activities around federated authentication and access management managed by Internet2 and its international partners

Shibboleth SpecificationsDeprecated?

Shibboleth SystemInternet2-developed open source implementation of the Shibboleth and SAML 2.0 specifications plus value-added components

Implementation of additional/complementary industry standards?

ShibbolethTimeline Project formation - Feb 2000

OpenSAML prerelease – July 2002

Shib v1.0 April 2003

Shib v1.2 April 2004

Shib v1.3 August 2005 (fully SAML 1.x compatible)…

OpenSAML 2.0 – Spring 2006

Shib 2.0 – Summer 2006

ShibbolethKey Concepts Federated Administration

Attribute-Based Single Sign-On

Management of Privacy through IdP

Standards Based

Framework for a Variety of Policy and Management Models

Extensible Authentication and Attribute Sharing

ShibbolethComponent Architecture

OpenSAML

Shibboleth Core Metadata Trust Credentials

SPCore

IdPCore

AttributeResolver

ARPEngine

NameIDResolver

SSO ServiceAttributeAuthority

AttributeFiltering

AccessControl

SessionCache

mod_shib, isapi_shib, etc.

Protocol HandlersProtocol Handlers

ApplicationsUser

Authentication

Shibboleth IdPApplication Model

Translates arbitrary act of authentication into SAML assertion containing claims about user

Claims (SAML attributes) can be pushed or pulled

User identity is masked in default configuration Claims to be released established by user or

administrative policy (usually the latter to date) Agnostic to authentication processes, attribute

sources (LDAP, JNDI, JDBC, custom)

Shibboleth SPApplication Model SP integrated with web platform (Apache, IIS,

Sun/iPlanet) validates SAML assertions and filters/processes the claims while providing session management (SAML token in, cookie out)

Applications generally written in terms of processed claims, but may access raw tokens

Interface between applications and claims is loosely-coupled and HTTP-centric (server environment variables)

Applications with existing security token mgmt can use a trivial “stub” application to translate incoming claims (store them in a database by session key, encrypt into cookie, map to local account or group, etc.)

ShibbolethRecent / Future Developments US Govt E-Authentication

Extension for Microsoft ADFS interoperability

Development of SAML 2.0 support underway

Early version of ARP GUI from Australia

Preliminary discussions over extending web SSO to back-end services

Liberty Alliance Project Open membership consortium, mostly

technology vendors and large corporate customers (consumer, telecom, financial)

Members generate business requirements (MRD) and produce technical specifications or profiles of standards to address requirements

Generally a pragmatic technical approach Also explores policy issues

ID-WSF Identity Web Services Framework

Uses the “web service stack” to define services useful to the Liberty sponsors’ business models

Examples include profile, contact book, social networking, calendaring, payment services, presence, geolocation, etc.

Relies on SAML and other open specs when possible

ID-WSF Security Requirements WS clients may invoke services on their own

behalf or on behalf of other identities, such as user principals.

Authz must be potentially enforceable both by a web service and by a trusted third party.

Authz may be based on the identity of the sender, the invoker, and the presence of the resource’s owner.

Basic Security Design Use TLS or signed XML when practical to

authenticate endpoints (peer entity authn)

Use WS-Security to carry security tokens, with SAML assertions the primary example

Bundles service discovery with security token issuance and TTP policy enforcement

Profiles SAML tokens for enhanced security semantics

Why is WSF significant?

Only adequately and publically-specified profiles for securing web services

Significantly extensible and adaptable without being hopelessly general

Driving mechanisms to enable more generic use of SAML

Related OASIS Standards

XACML (eXtensible Access Control ML) http://sunxacml.sourceforge.net/

SPML (Service Provisioning ML)

WS-Security SOAP Message Security

SAML Token Profile

WS-*

Large set of functionality that reinvents or tunnels existing protocols and standards on top of SOAP (e.g. TCP, TLS, Kerberos, XA)

Mostly proprietary specifications written by IBM or Microsoft

Slowly being fed to OASIS and W3C as they bring products to market

Designed to be “composable”, but the layering isn’t particularly clean or proven in real use cases

Very Incomplete List

Submitted WS-Security WS-Addressing (W3C) WS-SX

WS-Trust WS-SecureConversation WS-SecurityPolicy

WS-TX WS-Coordination WS-AtomicTransaction

WS-ReliableMessaging

Unsubmitted WS-Policy WS-PolicyAttachment WS-PolicyAssertions WS-MetadataExchange WS-Federation

An interoperable profile for using them in a real-world use case

Infocard

Microsoft developing a proprietary profile of WS-Trust + WS-SecurityPolicy + WS-MetadataExchange

OS-integrated client to manage delivery of credentials (e.g. SAML assertions) to relying parties that support WS-Trust

Integrated with Internet Explorer Client manages multiple keys to avoid

correlation by SPs