1. SAML http://www.oasis-open.org/committees/security/ http://www.opensaml.org/ Shibboleth http://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. 2 SAML Outline Background Use Cases Composition Implementations

3. 3 SAML Background / History Day 1: Man invents the HTTP browser Day 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 passes Day 2785: Deployer Man expects solutions to communicate. Vendor Man and Higher Ed Man have to agree on a standard.

4. 4 SAML Use Case Examples http://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. 5 SAML Background / 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. 6 Road to Convergence ID-FF 1.1 SAML 1.0SAML 1.1 Shibboleth 1.x ID-FF 1.2 SAML 2.0 Shibboleth 2.x (2005)

7. 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. 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. 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. 10 SAML Specifications Assertions Protocol(s) Protocol Bindings Profiles Conformance Metadata (2.0) Authentication Context (2.0)

11. 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. 12 SAML Assertions Example <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"> https://www.opensaml.org/IDP" scott@example.org http://www.opensaml.org/SP urn:oasis:names:tc:SAML:2.0:ac:classes:Password

13. 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. 14 Shibboleth Outline Overview Federations Roadmap

15. 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. 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. 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. 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. 19 High Level Architecture Knock, Knock… Service Provider Knock, Knock Service Provider Who’s There? Assertion Consumer Service v6597w54wd7 Authn Authority Mary Attribute Requester Attribute Authority v6597w54wd7 who? Attribute Requester Attribute Authority Mary, faculty, contract:001 Resource Let me in!

20. 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. 21 Technical Architecture OpenSAML Shibboleth Core MetadataTrustCredentials SP Core IdP Core Attribute Resolver ARP Engine NameID Resolver Authentication Authority (HS) Attribute Authority (AA) Attribute Filtering Access Control Session Cache mod_shib, isapi_shib, etc. Protocol Engine Applications User Authentication

22. 22 Outline Overview Federations Roadmap

23. 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. 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. 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. 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. 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. 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. 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. 30 Outline Overview Federations Roadmap

31. 31 Roadmap Mid 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. 32 Roadmap Late 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. 33 Roadmap 2005 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. 34 Roadmap 2005-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