1. Federated Identity Management: The Shibboleth Approach Renee Woodten Frost Internet2 Middleware and Security University of Michigan 22 March 2005

2. 22 Mar 2005Midwest Regional 2 Copyright Renee Woodten Frost, 2005. 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.

3. 22 Mar 2005Midwest Regional 3 Topics What is Identity Management (IdM)? Federated IdM? What is Shibboleth? Why Shibboleth? Federations –InQueue –InCommon For more information

4. 22 Mar 2005Midwest Regional 4 Identity Management (IdM) Set of standards, policies, procedures, and technologies that provide electronic credentials to individuals and maintain authoritative information about the holders of those credentials.. and assist in determining and granting access to resources and services.. Identity Management in this sense is sometimes called “Identity and Access Management” What problems does Identity Management solve?

5. 22 Mar 2005Midwest Regional 5 What We’re All Trying to Accomplish Simplify end user access to multitude of online services Facilitate operation of those services by IT organizations Increase security Enable online service for our constituents earlier in their affiliation with us, wherever they are, and ongoing Participate in new, inter-organizational, collaborative architectures and environments

6. 22 Mar 2005Midwest Regional 6 Federated Identity Management Relying on the Identity Management infrastructure of one or more institutions or units.. to authenticate and pass authorization-related information to service providers or resource- hosting institutions or enterprises.. via institution-provider agreements.. facilitated by common membership in a federation (like InCommon)

7. 22 Mar 2005Midwest Regional 7 Federated Administration O RP O RP Apps CM CM Apps VO RP Campus 1 Campus 2 Federation Other feds

8. 22 Mar 2005Midwest Regional 8 Federated Administration for HE Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so.. Build consistent campus and enterprise middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then Federate those enterprise deployments, using the outward facing campus infrastructure, with inter-realm attribute transports, trust services, etc. and then Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, and then, going forward Create tools and templates that support the management and collaboration of virtual organizations by building on the federated campus infrastructures.

9. 22 Mar 2005Midwest Regional 9 What is Middleware? Specialized networked services that are shared by applications and users A set of core software components that permit scaling of applications and networks Tools that take the complexity out of application integration A second layer of the IT infrastructure, sitting above the network A land where technology meets policy The intersection of what networks designers and applications developers each do not want to do

10. 22 Mar 2005Midwest Regional 10 A Map of Campus Middleware Land

11. 22 Mar 2005Midwest Regional 11 Core Middleware Scope Identity and Identifiers – namespaces, identifier crosswalks, real world levels of assurance, etc. Authentication – campus technologies and policies, interrealm interoperability via PKI, Kerberos, etc. Directories – enterprise directory services architectures and tools, standard objectclasses, interrealm and registry services Authorization – permissions and access controls, delegation, privacy management, etc. Integration Activities – open management tools, use of virtual, federated and hierarchical organizations, enabling common applications with core middleware

12. 22 Mar 2005Midwest Regional 12 Internet2 Middleware and the NSF Middleware Initiative (NMI) Internet2 Middleware a major theme for last five years, drawing support from 206 university members, 60+ corporate members, international partners and government grants and interactions Internet2 has integrator role within NMI, the key NSF Program to develop and deploy common middleware infrastructures NMI has two major themes –Scientific computing and data environments (ala Grids) –Common campus and inter-institutional middleware infrastructure (ala Internet2/EDUCAUSE/SURA work) Issues periodic NMI releases of software, services, architectures, objectclasses and best practices – R6 most current release in Dec 2005

13. 22 Mar 2005Midwest Regional 13 What is Shibboleth? (Biblical) A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce “sh”, called the word sibboleth. See - -Judges xii. Hence, the criterion, test, or watchword of a party; a party cry or pet phrase. Webster's Revised Unabridged Dictionary (1913)

14. 22 Mar 2005Midwest Regional 14 What is Shibboleth? An initiative to develop an architecture and policy framework supporting the sharing – between domains - - of secured web resources and services A framework built on a “Federated” model A project delivering an open source implementation of the architecture and framework Deliverables: –Software for identity providers = campuses (origins) –Software for resource providers (targets) –Operational Federations (scalable trust)

15. 22 Mar 2005Midwest Regional 15 Shibboleth Goals Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions Provide security while not degrading privacy –Using Attribute-based Access Control Foster inter-realm trust fabrics: federations and virtual organizations Leverage campus expertise and build rough consensus Influence the marketplace; develop where necessary Support heterogeneity and open standards

16. 22 Mar 2005Midwest Regional 16 Attribute-based Authorization Identity-based approach –The identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access. –This approach requires the user to trust the resource provider to protect privacy. Attribute-based approach –Attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. –This approach does not degrade privacy.

17. 22 Mar 2005Midwest Regional 17 Typical Attributes in the Higher Ed Community Affiliation“active member of community” member@washington.edu EPPN (eduPersonPrincipalName) Identitygettes@duke.edu EntitlementAn agreed upon opaque URI urn:mace:vendor:contract1234 OrgUnitDepartmentEconomics Department EnrolledCourseOpaque course identifier urn:mace:osu.edu:Physics201

18. 22 Mar 2005Midwest Regional 18 Addressing Four Scenarios Member of campus community accessing licensed resource –Anonymity required Member of a course accessing remotely controlled resource –Anonymity required Member of a workgroup accessing controlled resources –Controlled by unique identifiers (e.g. name) Intra-university information access –Controlled by a variety of identifiers Taken individually, each situation can be solved in a variety of straightforward ways. Taken together, they present the challenge of meeting users’ reasonable expectations for protection of personal privacy.

19. 22 Mar 2005Midwest Regional 19 So… What is Shibboleth? A Web Single-Signon System (SSO)? An Access Control Mechanism for Attributes? A Standard Interface and Vocabulary for Attributes? A Standard for Adding Authentication and Authorization to Applications?

20. 22 Mar 2005Midwest Regional 20 Shibboleth Architecture (still photo, no moving parts)

21. 22 Mar 2005Midwest Regional 21 Development Milestones Project formation - Feb 2000; process began late summer 2000 with bi-weekly calls to develop scenarios, requirements and architecture Linkages to SAML established - Dec 2000 Architecture and protocol completion - Aug 2001 Design - Oct 2001 Coding began - Nov 2001 Alpha-1 release - April 24, 2002 OpenSAML release - July 15, 2002 v1.0 April 2003; v1.1 July 2003; v1.2 May 2004 v1.3 Q1 2005 e-auth certified v1.4 Q1 2006 WS-Fed compliant v2.0 likely end of the major evolution

22. 22 Mar 2005Midwest Regional 22 Current Status: Shibboleth v. 1.2.1 Open-source, standards-based, privacy-preserving federating software Accelerating deployment globally: InCommon, NSDL, SWITCH, Finland, Netherlands, United Kingdom (three), Australia, InQueue, League of Federations Commercial information providers in production: Elsevier Science Direct, OCLC, etc. Resource Provider component works with Apache(1.3 and 2.0) and IIS Identity Provider component is Java-based for a variety of platforms Working on Underlying Attribute Authority GUI and resource protection Growing international development interest providing resource manager tools, email list software, etc.

23. 22 Mar 2005Midwest Regional 23 Shibboleth -- Next Steps Full Implementation of Trust Fabric –Supporting multi-federation origins and targets Support for Dynamic Content (Library-style Implementation in addition to web server plugins) Sysadmin GUIs for managing origin and target policy Integration with Grids, Virtual Organizations Integration with SAML V2.0, Liberty Alliance, WS-Fed NSF grant to Shibboleth-enable open source collaboration tools Integration with P2P - LionShare

24. 22 Mar 2005Midwest Regional 24 Why Shibboleth? Improved Access Control Use of attributes allows fine-grained access control –Med School Faculty get access to additional resources –Specific group of students have access to restricted resources Simplifies management of access to extended functionality –Librarians, based on their role, are given a higher-than- usual level of access to an online database to which a college might subscribe –Librarians and publishers can enforce complicated license agreements that may restrict access to special collections to small groups of faculty researchers

25. 22 Mar 2005Midwest Regional 25 Why Shibboleth? Federated Administration Flexibly partitions responsibility, policy, technology, and trust Leverages existing middleware infrastructure at origin - authentication, directory –Users registered only at their “home” or “origin” institution –Resource Provider does NOT need to create new userids Authorization information sent instead of authentication information –When possible, use groups instead of people on ACLs –Identity information still available for auditing and for applications that require it

26. 22 Mar 2005Midwest Regional 26 Why Shibboleth? Privacy Higher Ed has privacy obligations –In US, “FERPA” requires permission for release of most personal identification information; encourages least privilege in information access –HIPAA requires privacy in medical records handling General interest and concern for privacy is growing Shibboleth has active (vs. passive) privacy provisions “built in”

27. 22 Mar 2005Midwest Regional 27 Benefits to Campuses Much easier Inter-Domain Integration –With other campuses –With off-campus resource provider systems Integration with other campus systems, intra-domain –Learning Management Systems –Med School…… Ability to manage access control at a fine-grained level Allows personalization, without releasing identity Implement Shibboleth once… –And then just manage attributes that are released to new resource providers

28. 22 Mar 2005Midwest Regional 28 Benefits to Resource Providers Unified authentication mechanism from the vendor perspective –Much more scalable –Much less integration work required to bring new customers online Ability to implement fine-grained access control (e.g. access by role), allowing customer sites to effectively control access by attributes and thus control usage costs, by not granting access unnecessarily Once Shibboleth integration completed on vendor’s systems –Incremental cost of adding new customers is relatively minimal –In contrast to the current situation -- requiring custom work for each new customer Ability to offer personalization Enables attribute-based Service Level Model If universities have Shibboleth implemented already, easy implementation for them

29. 22 Mar 2005Midwest Regional 29 What are Federations? Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions Enroll and authenticate and attribute locally, act federally. Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) common attributes (e.g. eduPerson), and a security and privacy set of understandings Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision. Several federations now in construction or deployment

30. 22 Mar 2005Midwest Regional 30 Business drivers for R&E (again) Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so Build consistent campus middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then Federate (multilateral) those enterprise deployments with inter-realm attribute transports, trust services, etc. and then Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, from p2p to virtual organizations, etc. while we Be cautious about the limits of federations and look for alternative fabrics where appropriate.

31. 22 Mar 2005Midwest Regional 31 Policy Basics for Federations Enterprises that participate need to establish a trusted relationship with the operator of the federation; in small or bilateral federations, often one of the participants operates the federation Participants need to establish trust with each other on a per use or per application basis, balancing risk with the level of trust Participants need to agree on the syntax and semantics of the information to be shared Privacy issues must be addressed at several layers All this needs to be done on scalable basis, as number of participants grow and number of federations grow

32. 22 Mar 2005Midwest Regional 32 Unified Field Theory of Trust Bridged, global hierarchies of identification-oriented, often government-based trust: laws, identity tokens, etc. –Passports, drivers licenses –Future is typically PKI oriented Federated enterprise-based trust: leverages one’s security domain; often role-based –Enterprise does authentication and attributes –Federations of enterprises exchange assertions (identity & attributes) Peer-to-peer trust: ad hoc, small locus personal trust –A large part of our non-networked lives –New technology approaches to bring this into the electronic world. –Distinguishing P2P apps architecture from P2P trust Virtual organizations cross-stitch across one of the above

33. 22 Mar 2005Midwest Regional 33 Federal Guidelines of Relevance NIST Guideline on Risk Assessment Methodologies NIST Guideline on Authentication Technologies and their strengths Federal e-Authentication

34. 22 Mar 2005Midwest Regional 34 Shibboleth-based Federations InQueue InCommon Club Shib Swiss Education and Research Network (SWITCH) National Science Digital Library (NSDL) ------------------------------------ State networks Medical networks Financial aid networks Life-long learning communities

35. 22 Mar 2005Midwest Regional 35 The Research and Education Federation Space REF Cluster InQueue (a starting point) InCommo n SWITCH The Shib Resear ch Club Other national nets Other clusters Other potenti al US R+E feds State of Penn Fin Aid Assoc NSD L Slippery slope - Med Centers, etc Indiana

36. 22 Mar 2005Midwest Regional 36 InQueue The “holding pond” Is a persistent federation with “passing-through” membership… Operational today. Can apply for membership via http://shibboleth.internet2.edu/ InQueue Federation guidelines; approximately 150 participants http://shibboleth.internet2.edu/ Requires eduPerson attributes Operated by Internet2; open to almost anyone using Shibboleth in an R&E setting or not… Fees and service profile to be established shortly: cost-recovery basis

37. 22 Mar 2005Midwest Regional 37 InQueue Origins 2.12.04 Rutgers University University of Wisconsin New York University Georgia State University University of Washington University of California University at Buffalo Dartmouth College Michigan State University Georgetown Duke The Ohio State University UCLA Internet2 Carnegie Mellon University National Research Council of Canada Columbia University University of Virginia University of California, San Diego Brown University University of Minnesota Penn State University Cal Poly Pomona London School of Economics University of North Carolina at Chapel Hill University of Colorado at Boulder UT Arlington UTHSC-Houston University of Michigan University of Rochester University of Southern California

38. 22 Mar 2005Midwest Regional 38 Federation A permanent federation for the R&E US sector Federation operations – Internet2 Federating software – Shibboleth 1.2 and above Federation data schema - eduPerson200210 or later and eduOrg200210 or later Federated approach to security & privacy with posted policies Became fully operational mid-September, with several early entrants shaping the policy & process issues. Precursor federation, InQueue, in operation for about a year, feeds into InCommon http://www.incommonfederation.org http://www.incommonfederation.org

39. 22 Mar 2005Midwest Regional 39 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

40. 22 Mar 2005Midwest Regional 40 Uses Institutional users acquiring content from popular providers (Napster, etc.) and academic providers (Elsevier, OCLC, JSTOR, EBSCO, Pro-Quest, etc.) Institutions working with outsourced service providers, e.g. grading services, scheduling systems (Blackboard, WebCT, WebAssign, etc.) Inter-institutional collaborations, including shared courses and students, research computing sharing, etc. (Shared network security monitoring, interactions between students and federal applications, peering with international activities, etc.)

41. 22 Mar 2005Midwest Regional 41 Trust in - Initial Members trust the federated operations to perform its activities well –The operator (Internet2) posts its procedures, attempts to execute them faithfully, and makes no warranties –Enterprises read the procedures and decide if they want to become members Origins and targets trust each other bilaterally in out-of- band or no-band arrangements –Origins trust targets dispose of attributes properly –Targets trust origins to provide attributes accurately –Risks and liabilities managed by end enterprises, in separate ways

42. 22 Mar 2005Midwest Regional 42 Trust - Ongoing Use trust  Build trust cycle Clearly need consensus levels of I/A Multiple levels of I/A for different needs –Two factor for high-risk –Distinctive requirements (campus in Bejing or France, distance ed, mobility) Standardized data definitions unclear Audits unclear International issues

43. 22 Mar 2005Midwest Regional 43 Management Operational services by Internet2 –Member services (Application, etc) –Backroom (Certificate Authority, WAYF service, etc.) Governance –Steering Committee: Carrie Regenstein, Chair (Wisconsin), Jerry Campbell (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Ken Klingenstein (Internet2), Mark Luker (EDUCAUSE), Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teets (OCLC), David Yakimischak (JSTOR) –Two Steering Committee working groups Policy: Tracy Mitrano, Chair Communication, Membership, Pricing/Packaging: Susan Perry, Chair –Technical Advisory Group: Scott Cantor (OSU), Steven Carmody (Brown), Bob Morgan (Washington), Renee Shuey (PSU) Initially an LLC and likely to take 501(c)3 status

44. 22 Mar 2005Midwest Regional 44 Documents (to date) Membership criteria Pricing/packaging cost recovery model Federation Operating Practices and Procedures and Technical Operations Docs Participant Agreement Participant Operational Practice (POP)

45. 22 Mar 2005Midwest Regional 45 Participants Two types of participants: –Higher ed institutions -.edu-ish requirements –Resource providers – commercial partners sponsored by higher ed institutions, e.g. content providers, outsourced service providers, etc Participants can function in roles of identity providers and/or resource providers –Higher ed institutions are primarily identity (credential) providers, with the potential for multiple service providers on campus –Resource (service) providers are primarily offering a limited number of services, but can serve as credential providers for their employees as well

46. 22 Mar 2005Midwest Regional 46 Pricing 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 ResourceProviderIds included; additional ResourceProviderIds available at $50 each per year, available in bundles of 20

47. 22 Mar 2005Midwest Regional 47 Operations Operational services by Internet2 –Storefront (process maps, application process) –Backroom (CA, WAYF service, etc.) –Federation Operating Practices and Procedures (FOPP) InCommon Process Technical Advisory –Scott Cantor, OSU –Jim Jokl, University of Virginia –RL Bob Morgan, University of Washington –Jeff Schiller, MIT Key Signing Party –March 30, 2004 in Ann Arbor –Videotaped and witnessed

48. 22 Mar 2005Midwest Regional 48 Operations Docs InCommon_Federation_Disaster_Recovery_Procedures_ver_0.1 –An outline of the procedures to be used if there is a disaster with the InCommon Federation. Internet2_InCommon_Federation_Infrastructure_Technical_Refer ence_ver_0.2 –Document describing the federation infrastructure. Internet2_InCommon_secure_physical_storage_ver_0.2 –List of the physical objects and logs that will be securely stored. Internet2_InCommon_Technical_Operations_steps_ver_0.35 –This document lists the steps taken from the point of submitting CSR, Metadata, and CRL to issuing a signed cert, generation of signed metadata, and publishing the CRL. Internet2_InCommon_Technical_Operation_Hours_ver_0.12 –Documentation of the proposed hours of operations.

49. 22 Mar 2005Midwest Regional 49 CA Operations Docs CA_Disaster_Recovery_Procedure_ver_0.14 –An outline of the procedures to be used if there is a disaster with the CA. cspguide –Manual of the CA software planning to use. InCommon_CA_Audit_Log_ver_0.31 –Proposed details for logging related to the CA. Internet2_InCommon_CA_Disaster_Recovery_from_root_key_c ompromise_ver_0.2 –An outline of the procedures to be used if there is a root key compromise with the CA. Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61 –Draft of the PKI-Lite CPS. Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21 –Draft of the PKI-Lite CP. Internet2_InCommon_Certificate_Authority_for_the_InCommon _Federation_System_Technical_Reference_ver_0.41 –Document describing the CA.

50. 22 Mar 2005Midwest Regional 50 Key Signing Process 2. Hardware descriptions a. Hardware will be laptop and spare laptop with no network capabilities, thumb drive, CDRW drive, media for necessary software 3. Software descriptions a. OS, OpenSSL, CSP, Java tools for meta data 4. Log into computer 5. Generation of the CA Private Root key and self-signing 6. Generation of the Metadata signing key 7. Generate CSR for Internet2 origin 8. Signing of new metadata sites and trusts files 9. Backup copies of all private keys and other operational backup data are generated. 10. Verify CD's and MD5 checksum 11. Write down passphrase and put in envelopes and sign envelopes 12. Securely store CA hardware and contents of local safe in safe 13. Log that these actions occurred on the log in safe and then close and lock the safe 14. Put thumb drive into secure db and copy data onto secure db 15. Take private key password archive and other contents to Private Key Password safe deposit box and record in log that this was done. 16. Take operational data archive to Operation Data safe deposit box and record in log that this was done.

51. 22 Mar 2005Midwest Regional 51 The Potential for The federation as a networked trust facilitator Needs to scale in two fundamental ways –Policy underpinnings need to move to normative levels among the members; “post and read” is a starting place… –Inter-federation issues need to be engineered; we are trying to align structurally with emerging federal recommendations Needs to link with PKI and with federal and international activities If it does scale and grow, it could become a most significant component of cyberinfrastructure…

52. 22 Mar 2005Midwest Regional 52, some time from now Established with several hundred participants Multi-layered strength-of-trust threads among participants Working with state and/or regional federations “Peering” with national federations in other countries “Gateways” with commercial federations

53. 22 Mar 2005Midwest Regional 53 Acknowledgements Design Team: David Wasley (retired U of C); RL ‘Bob’ Morgan (Washington); Keith Hazelton (Wisconsin - Madison); Marlena Erdos (IBM/Tivoli); Steven Carmody (Brown); Scott Cantor (Ohio State) Important Contributions from: Ken Klingenstein (Internet2); Michael Gettes (Duke), Scott Fullerton (Wisconsin - Madison) Coding: Derek Atkins (MIT), Parviz Dousti (CMU), Scott Cantor (OSU), Walter Hoehn (Columbia/U of Memphis)

54. 22 Mar 2005Midwest Regional 54 For More Information Websites http://middleware.internet2.edu http://shibboleth.internet2.edu http:/www.incommonfederation.org Renee Woodten Frost rwfrost@internet2.edu