SAMLhttp://www.oasis-open.org/committees/security/http://www.opensaml.org/

Shibbolethhttp://shibboleth.internet2.edu/

SAMLhttp://www.oasis-open.org/committees/security/http://www.opensaml.org/

Shibbolethhttp://shibboleth.internet2.edu/

Scott Cantor (cantor.2@osu.edu)

Internet2/MACE and The Ohio State University

Scott Cantor (cantor.2@osu.edu)

Internet2/MACE and The Ohio State University

2

SAML Outline

Background

Use Cases

Composition

Implementations

3

SAMLBackground / History

Day 1: Man invents the HTTP browserDay 2: Man starts copying authentication protocols and adapting them to the web.Day 3: Vendor Man charges huge amounts of money for "web access management" solutions. Higher Ed Man invents his own (and another, and another…)…time passesDay 2785: Deployer Man expects solutions to communicate. Vendor Man and Higher Ed Man have to agree on a standard.

4

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

•Third-party authentication of browser to resource within or between security domains

•Single sign-on of browser to multiple resources within or between security domains

•Attribute exchange

•Delegated authorization decisions

•Attachable signed "tokens" for business messages

5

SAMLBackground / History

Initial standardization effort begun 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 builds on top of 1.0• SAML 1.1 completed and approved Sept 2003.• Liberty Alliance ID-FF 1.2 builds on top of 1.1• Liberty Alliance submits ID-FF to SSTC• SAML 2.0 committee draft approved August 2004, in public review

6

Road to Convergence

ID-FF 1.1

SAML 1.0 SAML 1.1

Shibboleth 1.x

ID-FF 1.2

SAML 2.0

Shibboleth 2.x(2005)

7

SAML 1.1

Shibboleth based directly on SAML 1.x:• SSO profiles initiated by identity provider• Query/response protocol for attributes

Lacking in interoperability…• Standardized “opaque” identifiers• Service provider initiated SSO• Metadata• Standardized attribute profiles

8

Liberty Alliance ID-FF 1.2

Builds on SAML 1.1 to specify a suite of protocols around “identity federation”, or account linking between providers.

Nice features:• Metadata format and exchange protocol• Rich protocol for requesting authentication, permits control over strength, interactivity, re-authentication

• Detailed “context” data about identification and authentication during SSO

9

SAML 2.0(Committee Draft as of Tuesday)

Vulcan mind-meld of SAML 1.1, Shibboleth 1.2, and Liberty ID-FF 1.2 technologies and profiles

Challenges:• Incorporate Liberty technical solutions into a generalized SAML framework

• Manage increase in size of specification• Maintain momentum, consistency• Support non-browser profiles in a consistent fashion (including, but not limited to, web services)

• Increased politicization

10

SAML Specifications

•Assertions

•Protocol(s)

•Protocol Bindings

•Profiles

•Conformance

•Metadata (2.0)

•Authentication Context (2.0)

11

SAML Assertions

An XML fragment binding a set of claims (statements) to a subject, issued by an authority to one or more relying parties:

• Issuer• Subject

– Identifier

– Confirmation

• Statement(s) (Authentication, Attribute, Authorization Decision, etc.)

• Conditions• Advice

12

SAML AssertionsExample

<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion"ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2003-04-17T00:46:02Z" Version="2.0"><saml:Issuer>https://www.opensaml.org/IDP"</saml:Issuer><Subject><NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">scott@example.org</NameIdentifier><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/></Subject><Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2003-04-17T00:51: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>

13

SAML Implementations

Toolkits• Many vendors offer libraries• Ping offers SourceID, open source but non-free for

commercial use (Java / .NET)• OpenSAML (Java / C++)

Web SSO• Many commercial products, varying support for attributes• SourceID• Shibboleth

Web Services• WS-Security Toolkits

14

Shibboleth Outline

Overview

Federations

Roadmap

15

Internet2/MACE

A consortium of over 200 research institutions, with corporate and government partners, developing technologies in support of the next generation of networking and applications.

MACE is a steering committee of about 20 technologists for middleware activities within Internet2.

16

MACE Working Groups

•MACE-Dir (eduPerson, LDAP Recipe)•Shibboleth•Course-ID•HEPKI (PKI-Light, S-MIME, HE Sector CA)•Signet (authority management)•VidMid (H.323, commObject)•MedMid (meduPerson, HIPPA privacy laws)•I2MM (Jabber, real-time communication/presence)•End to End Diagnostics

17

What is Shibboleth?1999-2003

•An Internet2/MACE initiative to develop a standards-based architecture and policy framework supporting the sharing of secured web resources and services

•A software project delivering an open source implementation of the architecture and framework

•Based on the OASIS SAML 1.1 specification (http://www.oasis-open.org/committees/security)

18

What is Shibboleth?2003-

•Open source attribute-based Web-SSO software with an emphasis on user privacy, built on the SAML specification

•A provider and consumer of innovations in federated identity standards

•An enabling technology for Internet2, international, and regional efforts at federation in education and research

19

High Level ArchitectureKnock, Knock…

ServiceProvider

Knock, Knock

ServiceProvider

Who’s There?

Assertion Consumer

Service

v6597w54wd7AuthnAuthority

Mary

AttributeRequester

AttributeAuthority

v6597w54wd7 who?

AttributeRequester

AttributeAuthority

Mary, faculty, contract:001

ResourceLet me in!

20

Shibboleth Project Deliverables

•An open source SAML implementation (http://www.opensaml.org/)

•Java-based “identity provider” implementation (authentication and attribute authorities)

•“Service provider” implementations for Apache, IIS, with additional deployment vehicles in development, including Java

•Federated PKI-based trust fabric

21

Technical Architecture

OpenSAML

Shibboleth Core Metadata Trust Credentials

SPCore

IdPCore

AttributeResolver

ARPEngine

NameIDResolver

AuthenticationAuthority (HS)

AttributeAuthority (AA)

AttributeFiltering

AccessControl

SessionCache

mod_shib, isapi_shib, etc.

Protocol EngineProtocol Engine

ApplicationsUser

Authentication

22

Outline

Overview

Federations

Roadmap

23

Federations

Shibboleth “federations” are sets of identity and service providers that share common trust and operational metadata.

Federations generalize bilateral arrangements between sites so policy can be delegated and scaled.

Deployments can span federations and bilateral agreements, and the implementation accomodates this.

24

Federation Services

•Vetting of identity providers

•Acting as naming authority for providers

•Aggregating, signing, publishing metadata

•Infrastructure for identity provider discovery

•Establishing ground rules for members

•Defining vocabularies of attributes and semantics

•Mediation and indemnification(in some deployments)

25

Federation Examples

•InQueue (Internet2 pilot federation)• http://inqueue.internet2.edu/

•InCommon (Internet2/US, forthcoming)• http://www.incommonfederation.org/

•SWITCH (Swiss federation)• http://www.switch.ch/aai/deployment.html

•Statewide initiatives

•Intra-university deployments

•Other international collaborations

26

InCommon Principles

•Support the R&E community in inter-institutional collaborations•InCommon itself operates at a high level of security and trustworthiness•InCommon requires its participants to post their relevant operational procedures on identity management, privacy, etc•InCommon will be constructive and help its participants move to higher levels of assurance as applications warrant•InCommon will work closely with other national and international federations

27

InCommon Uses

•Institutional users acquiring content from popular providers (Napster) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.)•Institutions working with outsourced service providers, e.g. grading services, scheduling systems•Inter-institutional collaborations, including shared courses and students, research computing sharing, etc.•Friction-remover for localized and regional efforts at federation

28

InCommon Pricing (Tentative)

Goals• Cost recovery• Manage federation “stress points”

Prices• Application Fee: $700 (largely enterprise I/A, db)• Yearly Fee

– Higher Ed participant: $1000 per identity management system

– Sponsored participant: $1000

– All participants: 20 service provider IDs included; additional IDs available at $50 each per year, available in bundles of 20

29

Lessons Learned

•Strong need for federation can drive deployment in spite of technology considerations.

•Top down federation is a long process.

•Identity provider discovery is a key branding/policy/support/UI issue for scaling federations

30

Outline

Overview

Federations

Roadmap

31

RoadmapMid 2004

•Shibboleth 1.2 and OpenSAML 1.0 released• Adoption of SAML 2.0 terminology, architecture• More compatibility with SAML 1.1 products• Increased modularity

•Early prototyping of management tools

•Application focus on information service providers

•InCommon federation in early rollout

•Project still centrally managed, controlled

32

RoadmapLate 2004

•Shibboleth 1.3• Support for SAML artifact profile• Reduced reliance on obsolete PKI functionality (mod_ssl)• Feature list still under discussion

•Federal E-Authn

•Early versions of management tools

•String of new production rollouts

•Improved system documentation

33

Roadmap2005

•Shibboleth 2.0 and OpenSAML 2.0• Migration to SAML 2.0 standard• Support for SAML WS-Federation features as practical and useful• Exploration of web services problem space (problem driven, not

technology or marketing-driven)

•Maturation of management tools

•Application focus on open source learning and collaboration tools, most of which are in Java

•Increased decentralization of development, research, direction-setting

34

Roadmap2005-2006

•Technical focus likely to move toward web services, middleware integration

•Personalized tools for managing privacy and access control to resources

•Application focus on grids, networks, DRM

•Increased commercialization of support and technology

•Increased interaction among education, government, commercial federations