1. Shibb oleth: Building Tools for Inter-institutional Resource Sharing InCommon: 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. 5 Feb 2005 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. 5 Feb 2005 A Map of Campus Middleware Land

5. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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 Credential Providers (campuses) Software for Resource Providers (content, services, etc) Operational Federations (scalable trust)

11. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 Typical Attributes in the Higher Ed Community Affiliation“active member of community”member@washington.edu EPPN (eduPersonPrincipalName) Identitygettes@duke.edu EntitlementAn agreed upon opaque URIurn:mace:vendor:contract1234 OrgUnitDepartmentEconomics Department EnrolledCourseOpaque course identifierurn:mace:osu.edu:Physics201

14. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 Shibboleth Architecture (still photo, no moving parts)

17. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 Federal Guidelines of Relevance  NIST Guideline on Risk Assessment Methodologies  NIST Guideline on Authentication Technologies and their strengths  Federal e-Authentication Efforts

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

32. 5 Feb 2005 The Research and Education Federation Space REF Cluster InQueue (a starting point) InCommon SWITCH The Shib Researc h Club Other national nets Other clusters Other potential US R+E feds State of Penn Fin Aid Assoc NSD L Slippery slope - Med Centers, etc Indiana

33. 5 Feb 2005 InQueue  The “holding pond”  Is a persistent federation with “passing-through” membership…  Operational today. Can apply for membership via http://shibboleth.internet2.edu 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. 5 Feb 2005 Some InQueue Credential Providers  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

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

36. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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_v er_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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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. 5 Feb 2005 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…

51. 5 Feb 2005 Leading Trust to Slaughter

52. 5 Feb 2005 Three Types of Issues  Internal federation issues Business drivers – educational, research, admin – helping each country find a reason Cookbook – key issues and common touchpoints Alignment with other trust services such as PKI  Inter-federation issues Needs for agreements –Authentication context, attributes Needs for legal frameworks –Assignment of roles within federation between –Treaties/MOU between federations  Union of federations issues

53. 5 Feb 2005 Inter-federation Agreements  Protocols Shib on the outside; generally Shib within Versioning issues  Data Authn context field – structure and values LOA – US Federal guidelines, the Australian points system, etc. Eduperson, eduOrg and cross-mappings Persistent identifiers  Trust Federation operations Inter-federation legal agreements Member statements –Formats –Controlled vocabulary

54. 5 Feb 2005 League of Federations  Brand, logo, presence  Handling international resource-providers  Qualifying new members  Relationship to other sector activities, particularly government (and health services)  Support for virtual organizations  Promoting its use for applications: eduRoam, GLIF, Grids  EU Privacy issues  International WAYF  Universal InQueue

55. 5 Feb 2005 Leading Trust from Slaughter

56. 5 Feb 2005 Immediate International Issues  “International WAYF” – management of the user experience List of Federations that contain IdPs Where to put multi-nationals? Handling of exceptions in a consistent fashion  Privacy EU Privacy directives intended for attributes associated with identity Rules for interior and exterior privacy may be different for EU And then there’s the Swiss…

57. 5 Feb 2005 Federal Government  Federal E-Authentication has a number of pilots under way. One of them is now Shib.  Phase 1 and Phase 2 efforts funded, with deliverables due over the next six months Policy framework comparison submitted Oct 7 Technical interoperability demonstrated October 14 Policy discussions and applications meetings now occurring  Potential phase 3 and 4 would include working on a federal federation and peering with Higher Ed and other federations – meetings underway

58. 5 Feb 2005 WS-Fed and Shib  Verbal agreements to build WS-Fed interoperability Contract work commissioned by Microsoft, executed by Shib core development Contracts executed and work likely this Spring  Discussions broached, by Microsoft, in building Shib interoperabilty into WS-Fed  Devils in the details

59. 5 Feb 2005 For More Information  Websites http://middleware.internet2.edu http://shibboleth.internet2.edu http:/www.incommonfederation.org Renee Woodten Frostrwfrost@internet2.edu