1. 7 October 2015 Shibboleth

2. Agenda  Shibboleth Background and Status  Why is Shibboleth Important (to Higher Ed)?  Current Pilots Course Management Library Pilots Other Pilot Projects  Next Steps

3.  Shibboleth Background and Status  Why is Shibboleth Important?  Current Pilots  Next Steps

4. What is Shibboleth?  An initiative to develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services  A project delivering an open source implementation of the architecture and framework What is Shibboleth?

5.  A system...  with an emphasis on privacy users control release of their attributes  based on open standards (SAML) and available in open source form  built on “federated administration”

6. Attribute-based authorization  There is a spectrum of approaches available for attribute-based management of access to controlled resources, At one end is the attribute-based approach, where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach does not degrade privacy. At the other end is the identity-based approach, where 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. Since this leads with identity, this approach requires the user to trust the target to protect privacy.

7. Stage 1 - Addressing Four Scenario’s  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 of these situations can be solved in a variety of straightforward ways.  Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy.

8. High Level Architecture  Destination and origin site collaborate to provide a privacy-preserving “context” for Shibboleth users  Origin site authenticates user  Destination site requests attributes about user directly from origin site  Users (and organizations) can control what attributes are released

9. Technical Components  Origin Site – Required Enterprise Infrastructure Authentication Attribute Repository  Origin Site – Shib Components Handle Server Attribute Authority  Target Site - Required Enterprise Infrastructure Web Server (Apache or IIS)  Target Site – Shib Components SHIRE SHAR WAYF Resource Manager

10. From Shibboleth Arch doc OriginTarget

11. From Shibboleth Arch doc OriginTarget

12. Attribute Authority --Management of Attribute Release Policies  The AA provides ARP management tools/interfaces. Different ARPs for different targets Each ARP Specifies which attributes and which values to release Institutional ARPs (default) –administrative default policies and default attributes –Site can force include and exclude User ARPs managed via “MyAA” web interface Release set determined by “combining” Default and User ARP for the specified resource

13. Typical Attributes in the Higher Ed Community Affiliation“active member of community” member@washington.e du EPPNIdentitygettes@duke.edu EntitlementAn agreed upon opaque URI urn:mace:vendor:contra ct1234 OrgUnitDepartmentEconomics Department EnrolledCourseOpaque course identifier urn:mace:osu.edu:Phys ics201

14. Managing Trust  When a target receives a request to create a session, the Authn Assertion must be signed (PKI validation), and the origin must be a member of a common Federation.  (today) When an Origin receives a request for attributes, it must be transported across SSL. The name of the Requestor is used to locate the appropriate ARP.

15. Target – Managing Attribute Acceptance  IC will NOT require members to do business with each other  So, targets will NOT have to accept attributes from every origin  Targets use Attribute Acceptance Policies

16. Managing Authorization  Target manages rules specifying what attributes must be supplied in order to gain access  Rules are attribute based

17. Various Federation Deploy Models  A target can be a member of multiple federations.  For each transaction, it will determine the origin, and the federation that origin belongs to, and the policies that federation is operating under  (Currently), an origin can be a member of only one federation.. So a campus that is in multiple federations would have to deploy multiple instances of the Shib origin software…  Soon… support for a multi-federation origin.

18. InCommon  A federation to support academic and research activities.  Members can be organizations that are : origins (IdSP’s) targets (student loan services, content providers) both (universities, museums, etc.)  Federation functions : Central registry service and WAYF service Origin practices on attributes and authentication Target practices on the management of exchanged attributes Attribute sets (eduPerson and eduOrg) for use to exchange attributes

19. InCommon Operation  Operated by Internet2, open to all interested parties; registration fees modest and likely absorbed internally for Internet2 members  Initial governance by NPPAC (I2 CIO policy/planning council) with the intent to propose a light-weight governance structure to club members  Registration services on line; distribution of registry updates nightly  Self-audits by members

20. Shibboleth Status  Version 1.1 available summer 2003 Target support for Apache and IIS Origin implemented in java Supports ldap and SQL repositories  InQueue operational, InCommon soon  25 campuses have deployed Shib origins  Growing vendor activity Information vendors (eg JSTOR, EBSCO, etc) Admin App’s

21.  Shibboleth Background and Status  Why is Shibboleth Important?  Current Pilots  Next Steps

22. Why Shibboleth?  Higher Ed is a collaborative enterprise Faculty have strong ties to peers at other institutions With wed-based IMS systems, faculty share resources with their peers  Research is a collaborative enterprise During the next three to five years, Brown will establish several multidisciplinary centers or institutes that will bring faculty expertise and resources together in optimal ways, possibly through collaboration with other institutions. - Robert Zimmer, Provost, Brown University “Research in the future will be all about collaboration and distributed research groups that are facilitated through technology.” - Andries van Dam, VP Research, Brown University

23. Why Shibboleth? Security  Better security tools will make collaboration more “painless” and more secure  Current "solutions" are primitive; we can do better today and without local overhaul  Shibboleth Simplifies Management and Use of Distributed Systems

24. Why Shibboleth? Improved Access Control  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. Why Shibboleth? Federated Administration  Users registered only at their “home” or “origin” institution  Flexibly partitions responsibility, policy, technology, and trust  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. 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  General interest and concern for privacy is growing  Shibboleth has active (vs. passive) privacy provisions “built in”

27.  Shibboleth Background and Status  Why is Shibboleth Important  Current Pilots  Next Steps

28. Current Pilots  Course Management  Library Pilots  Other Pilot Projects

29. Course Management  WebCT  BlackBoard  Webassign

30. Library Pilot  A dozen+ campuses working with 6 information vendors  Using Shibboleth to control access to electronic resources  Good test case for privacy requirements, trust model needs

31. Project Goals  Explore and Evaluate the utility of the Shibboleth model (attributes) for controlling access to licensed resources  Identify problems and issues with this approach How well do existing licenses map to attributes? Library “walk-in” customers Physical location sometimes important (being “in” the Law Library) Managing an environment with both Shib’ed and non- Shib’ed resources

32. Campus Participants  Carnegie Mellon  Columbia  Dartmouth  Georgetown  London School of Economics  New York Unv.  Ohio State Penn State U. Colorado U. Michigan U. Washington U. Wisconsin – Madison UCOP (U. California System) U.Texas Health Science Center at Houston

33. Vendor Participants  EBSCO  Elsevier  OCLC  Sfx (Ex libris)  JSTOR  McGraw Hill eBooks

34. Shibboleth Deployment Issues  Access Issues  Kiosks and walk-ins  logins for on-campus use  Licensing issues  reconciling license structures with directory structures  system and consortial issues  mitigating disintermediation  Functional issues  handling Shibbed and non-Shibbed resources  roll-out strategies  entitlements vs attributes  what attributes to pass  how to structure the attribute name space

35. Other Pilot Projects  Univ Admin Applications  Student Financial Aid (eg Meteor)  American Association of Medical Colleges  NSDL (National Science Digital Library)  SWITCH - The Swiss National Academic Community  UK/JISC - Controlled Access to Licensed Resources  Univ Texas, Medical Center and instruction  Washington Research Library Consortium (WRLC)

36.  Shibboleth Background and Status  Why is Shibboleth Important  Current Pilots  Next Steps

37. Next Steps  Get InCommon Operational  Non-Web Use Cases Federated P2P (LionShare) Information Access (WebDAV, Streaming Server) Collaboration (IM, VideoConference) 3-tier  GUI - Attribute Release Policy Management  Native java-based target implementation

38. 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 Authn and Authz to Applications?