Renee Woodten Frost Internet2 Middleware and Security 5 Feb 2005

1. Shibboleth: Building Tools for Inter-institutional Resource SharingInCommon:A Shibboleth-based Research and Education Federation Renee Woodten Frost Internet2 Middleware and Security 5 Feb 2005

2. Topics • A Bit O’ Background - Internet2, Middleware, NMI • What is Shibboleth? What is its Current Status? • Why Shibboleth? Who is Using Shibboleth? • What are Federations? • InCommon • Work with Other Federations • International R&E Federations • Federal e-Authentication work • Commercial – WS-Fed • For more information

3. 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

4. A Map of Campus Middleware Land

5. 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

6. MACE (Middleware Architecture Committee for Education) • Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher education • Membership - Bob Morgan (UW) Chair, Tom Barton (Chicago), Scott Cantor (Ohio State), Steven Carmody (Brown), Michael Gettes (Duke), Keith Hazelton (Wisconsin), Paul Hill (MIT), Jim Jokl (Virginia), Mark Poepping (CMU), Lynn McRae (Stanford), David Wasley (retired California), Von Welch (Grid) • European members - Brian Gilmore (Edinburgh), Ton Verschuren (Netherlands), Diego Lopez (Spain) • Creates working groups in major areas, including directories, interrealm access control, PKI, video, P2P, etc. • Works via conference calls, emails, occasional serendipitous in-person meetings...

7. Internet2 Middleware and the NSF Middleware Initiative (NMI) • Internet2 Middleware a major theme for the last five years, drawing support from 200+ university members, 75+ corporate members, and government grants and interactions • Internet2 has an 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 (Grids) • Common campus and inter-institutional middleware infrastructure (Internet2/EDUCAUSE/SURA work) • Issues periodic NMI releases of software, services, architectures, objectclasses and best practices • R6 in Dec 04 most current release

8. The Model:Enterprises and Federation 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 this 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. 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)

10. What is Shibboleth? • An initiative to develop an architecture and policyframework 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 Credential Providers (campuses) • Software for Resource Providers (content, services, etc) • Operational Federations (scalable trust)

11. 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

12. 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 target 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.

13. Typical Attributes in the Higher Ed Community

14. 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.

15. 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?

16. Shibboleth Architecture (still photo, no moving parts)

17. Shib Update • Project formation - Feb 2000 • Inception of SAML effort in OASIS – December 2000 • OpenSAML release – July 2002 • Shib v1.0 April 2003 • Shib v1.1 July 2003 • Shib v1.2 April 2004; Shib v1.2.1 November 2004 • Shib v1.3 1Q05 – non web services, e-Auth certified • Shib v1.4 WS-Fed compliant • OpenSAML 2.0 – relatively soon • Shib 2.0 – 3Q05?

18. Shibboleth Status • Campus adoption accelerating and working with increasing number of information/service providers - over 50 universities using it for access to OCLC, JSTOR, Elsevier, WebAssign, Napster, etc. • Common status is “moving into production” • The hard part is not installing Shibboleth but running “plumbing” to it: directories, attributes, authentication • Work underway on some of the essential management tools such as attribute release managers, resource management, etc. • Needs federations to scale; being adopted by, or catalyzing, national R&E federations in several countries

19. Shibboleth Status • Likely to coexist well with Liberty Alliance and may work within the WS framework from Microsoft. • Growing development interest in several countries - providing resource manager tools, listprocs, etc. • UK’s JISC 2004 awards for Core Middleware: Technology Development Programme – 8 of 15 involve Shib • Used by several federations today – NSDL, InQueue, SWITCH, and several more soon (UK, Australia, Finland, etc.)

20. Shibboleth – Some Next Steps • Full Implementation of Trust Fabric • Supporting multi-federation credential and resource providers • Support for Dynamic Content • SysAdmin GUIs for managing credential and resource policy • Integration with SAML V2.0, Liberty Alliance, WS-Fed • NSF grant to Integrate Shib with Grids • NSF grant to Shibboleth-enable open source collaboration tools

21. 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

22. Why Shibboleth?Federated Administration • Flexibly partitions responsibility, policy, technology, and trust • Leverages existing middleware infrastructure at home organization/credential provider - 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 Access Control Lists • Identity information still available for auditing and for applications that require it

23. 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”

24. Benefits to Campuses • Much easier Inter-Domain Integration • With other campuses • With off-campus service provider systems • Integration with other campus systems, intra-domain • Learning Management Systems • Individual dept/school-specific needs • 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

25. Benefits to Resource Providers • Unified authentication mechanism from the vendor perspective • Much more scalable • Much less integration work required to bring a new customer 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 work 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

26. What are Federations? Associations of enterprises that come together to exchange information about their users and resources to enable collaborations and transactions • Enroll and authenticate and attribute locally, act federally. • Uses federating software (e.g. Shibboleth), common attributes (e.g. eduPerson), and a set of security and privacy understandings • Enterprises/users retain control over attributes released to resource; Resources retain control (may delegate) over authorization decisions

27. Business drivers for federations • Research and education • Access to and sharing of digital content • The visiting scientist and eduRoam • Inter-institutional courseware • Grids and collaborative tools

28. Requirements for federations • Federation operations • Federating software • Exchange assertions • Link and unlink identities • Federation data schema • Federation privacy and security requirements • Federations should be positioned to support both web services and direct applications

29. 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 shared attributes • Privacy issues must be addressed at several layers • All this needs to be done on a scalable basis, as the number of participants grow and the number of federations grow

30. Federal Guidelines of Relevance • NIST Guideline on Risk Assessment Methodologies • NIST Guideline on Authentication Technologies and their strengths • Federal e-Authentication Efforts

31. US Shibboleth Federations • InQueue • InCommon • Uses • Management • Policies • Shared schema • Club Shib • NSDL • State, system, and campus federations • Texas, Ohio State, etc…

32. REF Cluster InQueue (a starting point) Other clusters Other potential US R+E feds Other national nets SWITCH InCommon NSDL The Shib Research Club State of Penn Fin Aid Assoc The Research and EducationFederation Space Indiana Slippery slope - Med Centers, etc

33. InQueue • The “holding pond” • Is a persistent federation with “passing-through” membership… • Operational today. Can apply for membership via 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

34. Brown University Cal Poly Pomona Carnegie Mellon University Columbia University Cornell University Dartmouth College Duke University Georgetown University Georgia State University Internet2 London School of Economics Michigan State University National Research Council of Canada New York University Penn State University Rutgers University The Ohio State University The University of Kansas University of Alaska Fairbanks University of Arkansas University of Bristol University of Buffalo UCLA University of California, San Diego University of California Shibboleth Pilot University of Colorado at Boulder University of Michigan University of Minnesota University of Missouri - Columbia University of North Carolina at Chapel Hill University of Rochester University of South Dakota University of Southern California UT Arlington UTHSC-Houston University of Virginia University of Wisconsin Some InQueue Credential Providers

35. What is InCommon? • A Shibboleth-based Research and Education Federation for the US • A public-sector, large-scale, persistent federation

36. Federation • Federation operations – Internet2 • Federating software – Shibboleth 1.2 and above • Federation data schema - eduPerson200210 or later and eduOrg200210 or later • Federated approach to security and privacy with posted policies • Became fully operational mid-September, with several early entrants shaping the policy issues. • Precursor federation, InQueue, has been in operation for about a year and will feed into InCommon; approximately 150 members • http://www.incommonfederation.org

37. 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

38. Uses • Institutional users acquiring content from popular providers (Napster, etc.) and academic providers (Elsevier, JSTOR, OCLC, 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. • (Shared network security monitoring, interactions between students and federal applications, peering with international activities, etc.)

39. Management • Legal - initially LLC, likely to take 501(c)3 status • Governance • Steering Committee: Carrie Regenstein, chair (Wisconsin), Jerry Campbell (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Ken Klingenstein (I2), Mark Luker (EDUCAUSE), Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teets (OCLC), David Yakimischak (JSTOR) • Two Steering Committee advisory groups • Policy: Tracy Mitrano, Chair • Communications, Membership, Pricing, Packaging: Susan Perry, Chair • Technical Advisory Group: Scott Cantor (OSU), Steven Carmody (Brown), Bob Morgan (UWash), Renee Shuey (PSU) • Project manager: Renee Woodten Frost (Internet2)

40. 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

41. 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 some of their employees as well

42. 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

43. Trust in - initial • Members trust the federated operators to perform its activities well • The operator (Internet2) posts its procedures • Enterprises read the procedures and decide if they want to become members • Contracts address operational and legal issues • Origins and targets establish trust bilaterally in out-of-band or no-band arrangements (using shared posting of practices) • Origins must trust targets dispose of attributes properly • Targets must trust origins to provide attributes accurately • Risks and liabilities managed by end enterprises, in separate ways • Collaborative apps are generally approved within the federation • Higher risk apps address issues through contractual and legal means

44. Members trust Operations • The federation operations presents limited but real exposures in identity proofing members properly and in the metadata management • InCommon publishes its procedures for identity proofing and its operational procedures • InCommon Certificate Authority CP/CPS • Metadata management process • Individual enterprises read the policies and decide whether to trust the federation operations and how to assign liability

45. 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_Reference_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.

46. 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_compromise_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.

47. Participant Agreement Highlights • Agree to post policies • Security • Basic identity management • Privacy • Inform InCommon on a timely basis of key compromise • Be responsible for ResourceProviderIds issued • Be responsible for adhering to their POPS statement • Stay timely on metadata

48. Members Trusting Each Other:Participant Operational Practice Statement • Basic Campus identity management practices in a short, structured presentation • Identity proofing, credential delivery and repeated authentication • Provisioning of enterprise-wide attributes, including entitlements and privileges • Basic privacy management policies • Standard privacy plus • Received attribute management and disposal

49. Trust Pivot Points in Federations • In response to real business drivers and feasible technologies, need to increase the strengths of: • Campus/enterprise identification, authentication practices • Federation operations, auditing thereof • Campus middleware infrastructure in support of Shib (including directories, attribute authorities and other Shib components) and auditing thereof • Relying party middleware infrastructure in support of Shib • Moving in general from self-certification to external certification

50. International Federation Peering • Shibboleth-based federations in the UK, Netherlands, Finland, Switzerland, Australia, Spain, and others • International peering meeting October 14-15 in Upper Slaughter, England • Issues include agreeing on policy framework, comparing policies, correlating app usage to trust level, aligning privacy needs, working with multinational service providers, scaling the WAYF function • Leading trust to Slaughter…