Shibboleth Architecture and Requirements

1. Shibboleth Architecture and Requirements Shibboleth A New Approach to Web Based Access Control CNI April 4, 2005

2. Overview • Shibboleth Update • Introduction to Shibboleth • Project Status • InCommon Status • Adoption Status • How Are Campuses Using Shibboleth Today? • The Conversion from IP-based Access Control to Shibboleth • … Open Discussion

3. What is Shibboleth? • An Architecture and Protocol • A set of profiles based on the OASIS SAML 1.1 standard • A Project sponsored by Internet2/MACE • Charged with defining the Shibboleth Arch, developing an open source implementation, and supporting the deploy of Shibboleth through the Higher Ed environment • Develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services • An Implementation of the Shibboleth Architecture • Developed by the I2/MACE Shibboleth Project • There are other independent implementations

4. Key Concepts • A Secure Framework for Managing Access Control • Access Control Based On Attributes • Active Management of Privacy • Standards Based • Federated Administration • A Framework for Multiple, Scaleable Trust and Policy Sets (Federations). • A Standard (yet extensible) AttributeValue Vocabulary

5. Attribute-based Authorization • IP Address-based approach • The resource checks the browser's IP address against a table. Browsers using an IP address assigned to campus X are given campus X’s authorizations • Most campuses run proxy servers, to allow access from off-campus • Identity-based approach • The identity of a prospective user is passed to the controlled resource and is used to determine whether to permit access. • This approach requires the user to trust the resource to protect privacy. • Attribute-based approach • Attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. Identity MAY be an attribute… • This approach does not degrade privacy.

6. Benefits to Campuses • Much easier Inter-Domain Integration • With other campuses • With off-campus vendor systems • Integration with other campus systems, intra-domain • LMS • Med School…… • Ability to manage access control at a fine-grained level • Allows personalization of services, without releasing identity • Implement Shibboleth once… • And then just manage attributes that are released to new targets

7. Benefits to Services/Vendors • Shibboleth is built on open standards • 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 the initial Shibboleth integration work has been completed on the vendor’s systems • The 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 • If your customers have Shibboleth implemented, easy implementation of service for them

8. Shibboleth (the Implementation) Status • V1.2.1 available fall 2004 • In production use by commercial information providers (eg EBSCO, Elsevier SD, OCLC) • Growing international takeup (countrywide deploys in HE underway in Switzerland, Finland, UK, Australia, and others…) • Deploy rate on US campuses accelerating…. • Production Federations now available • Recent meeting of “League of Federations” • On track for certification by US Federal E-Authn Initiative

9. Shibboleth -- Next Steps • Plan for a Multi-Federation World • Improved management tools • Shibboleth 1.3 available May 2005 • Reduces reliance on inflexible PKI validation code • e-Auth, compliance • WS-Fed compliance in 1.3.x • Shibboleth 2.0, using SAML 2.0, represents greatly enhanced functionality; work begins after 1.3 is released • Shibboleth project will be segmented and expanded • Extended beyond the web; some flows may not use all existing components in the same way

10. What are federations? • An association of organizations that use a common set of attributes, practices and policies to exchange information about their users and resources in order to enable collaborations and transactions. • Built on the premise of • “Enroll and authenticate and attribute locally, act federally.” • Federation provides only modest operational support and consistency in how members communicate with each other • 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. • Over time, this will all change…

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

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

13. 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.)

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

15. Adoption Status - Campuses • So you’ve got a Shibboleth IdP operational • … and you’re wondering “what do I do with it?” • … here are profiles of several campuses, describing their plans for using Shibboleth to control access to services in the intra- and inter-domain

16. How Are Campuses Using Shibboleth Today? • 150+ campuses at some stage of deploy • Some Examples • Penn State • Ohio State University • Duke • Univ of Texas System • Univ of Southern California

17. Penn State • Strategy • Position your university for a new way of doing business with federated approach • Take privacy issues seriously • Targets of opportunity

18. Penn State • Sequence – currently in production • WebAssign + Physics Dept • Physics Dept maintaining 1000+ userids and passwords every semester at a remote site • Shibboleth got them out of that business • Help desk calls related to password problems dropped 75% • Napster • Authenticated access • preserve privacy • Indicate whether or not user is authorized to use service

19. Penn State • Next steps • Pennsyvania Higher Education Assistance Agency(PHEAA) • Piloting:  with • Digital Library Technology department, • OCLC, • JSTOR, • Elsevier • ProQuest • LionShare's – secure P2P file sharing

20. Ohio State • Strategy • Establish a comfort level running and supporting the software and ironing out usability problems while staying internal so that the coordination and support issues are simpler. • The priority is on converting existing applications…. Don't know when the external opportunities will be important enough to pursue • Deploying it internally is a bet that the external applications will be important in the future

21. Ohio State • Sequence • Internal library application (EZProxy) (authn will no longer mean authz) • Internal low-volume/impact applications (begin replacing local SSO) • External library applications (Jstor/EBSCO/OhioLink/etc) • Internal high-volume applications

22. University of Texas & UT Federation • 16 institutions with origins used for inter-institutional access. • Authenticated wireless access at the UT System Office. • UT institutions – cross institution security site. • Being strongly considered for authX for the employee benefits system for all 16 institutions. • Pilot for library access • A UT Federation provides some shortcuts through the policy and legal processes as all of the institutions fall under the same governing board and legal service.

23. Across Texas • UT Houston and Baylor will be using shib enabled web application for medical resident evaluations. This is considered by AAMC as a very common issue. • Being considered for cross institutional access to web based resources in the Texas Medical Center (44 independent institutions). First will be the Texas Medical Center Library via ETR grant. • Rice and A&M are considering sharing some library resources.

24. Univ. of Southern California • Currently in Production • Napster (music download service) -- different levels of service are available to different audiences; the subsets currently are 'students' and 'faculty' (or maybe 'faculty/staff'). • Scholar's Portal (specialized library portal) -- see http://library.usc.edu/ (click link at the upper right); I think this is open to anyone in the USC community • myUSC Portal (general web portal) -- See https://my.usc.edu/ -- everybody at USC • Software.usc.edu -- the software download server for desktop sw licensed generally to USC (e.g., Acrobat Pro, Symantec, Timbuktu etc etc); • Assorted random stuff ( e.g. blogs, asst departmental apps, like music, theater & USCard)

25. Univ. of Southern California • “Real Soon Now” • Blackboard • Library online resources (e.g., EBSCO) • Webreg -- web-based class registration

26. Adoption Status - International • UK - JISC has decreed that Shibboleth will replace Athens SSO by 2007 • Switzerland • deployed at all all HE sites • Access to licensed resources • Finland • Countrywide Shib-enabled MetaLib • Australia • Access to licensed resources • Shib-enabled Dspace • China • Pilots underway…..

27. Content Provider Adoption • Elsevier Science Direct • OCLC • EBSCO • JSTOR • ArtStor • Pro-Quest • Exlibris (sfx, MetaLib) • Dynix • Thompson/Gale • EZProxy • LMS Systems (Blackboard, WebCT, Sakai..?) • ….

28. The Conversion from IP-based Access Control to Shibboleth • Role of the Library • Manage licenses • Manage Attribute Release • Role of the Campus IT Organization • Operate the campus middleware infrastructure • Operate the Person Registry (and attributes) • Operate the Shibboleth infrastructure • Role of the Federation • Manage the metadata • Manage the trust infrastructure

29. Managing the Conversion - • Managing the Mixed Environment • Mix of Shib-enabled and non-Shib-enabled vendors • Persistence of URLs when a vendor converts to Shibboleth (eg on a course web page) • The Changing User experience • Login now required, even on campus • Authorization implemented – some people may no longer have access • Other Issues • Library walkins • Avoiding the Federation WAYF

30. Why Campuses Should Begin the Transition Now… • Compelling Applications Becoming Available • 30 “outward-facing” Federal applications by Oct 2005 • Once a campus deploys Shibboleth, all applications can use it. • The library transition can leverage existing IT effort • Shibboleth addresses current problems • Problems with IP (access from off-campus, guest access to campus IP space) • Problems with Proxies • Problems managing “charge per search” situations • Shibboleth provides additional functionality and flexibility • Personalization with privacy • Fine-grained access control by community • Fine-grained control with sfx

31. Open Discussion • Questions? • What are Your Concerns about Migrating to Shibboleth? • What Topics Should we Cover During the ALA Workshop?