Shibboleth Architecture and Requirements

1. Shibboleth Architecture and Requirements Shibboleth A New Approach to Web Based Access Control NERCOMP March 8, 2005

2. Overview • Introduction to Shibboleth • How Are Campuses Using Shibboleth Today? • Shibboleth – How Does it Work? • The InCommon Federation

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 • Federated Administration • Access Control Based On Attributes • Active Management of Privacy • Standards Based • A Framework for Multiple, Scaleable Trust and Policy Sets (Federations). • A Standard (yet extensible) AttributeValue Vocabulary

5. 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. • Attribute-based Access Control • Foster interrealm trust fabrics: federations and virtual organizations • Leverage campus expertise and build rough consensus • Influence the marketplace; develop where necessary • Support for heterogenity and open standards

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

7. Shibboleth Status • V1.2.1 available fall 2004 • In production use by commercial information providers (eg 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

8. 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…

9. Shibboleth -- Next Steps • Plan for a Multi-Federation World • Improved management tools • Shibboleth 1.3 early 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. 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

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

12. How Are Campuses Using Shibboleth Today? • Penn State • Ohio State University • Duke • Univ of Texas System • Univ of Southern California

13. What Next… • 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

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

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

16. Penn State • Next steps • Pennsyvania Higher Education Assistance Agency(PHEAA) • Piloting:  with our Digital Library Technology department, OCLC, JSTOR, Elsevier and ProQuest • LionShare's use of the AA for attributes

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

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

19. Duke and Shibboleth • Parking (June 2004) • The App runs on IIS and our WebAuth does not. Solved! • The App had problems, not shib! • Kenexa • Outsourced HR performance App for Duke Health System

20. Duke and Shibble-ware • Actively working on Ex-Libris and friends for our Libraries • Various MacOSX based applications….. • Student Health Services deployed a windows server app and needed shibbing

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

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

23. Univ. of Southern California • Strategy • Started out with authN only in the form of PubCookie with a Kerberos back-end. This was deployed within ISD and spottily across campus. • Now moving to authZ with authN using Shibboleth and a Kerberos back-end.

24. USC - Sequence • 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. USC - Sequence • “Real Soon Now” • Blackboard • Library online resources (e.g., EBSCO) • Webreg -- web-based class registration

26. Shibboleth – How Does it Work?

27. WAYF Service Provider Web Site Identity Provider 5 3 2 4 6 1 7 Credentials 8 ACS HS Handle User DB Handle Resource Resource Manager 9 Handle AA AR Attributes 10 Attributes © SWITCH The Architecture of Shibboleth

28. Shibboleth: The Project, the Architecture, and the Code • Project encompasses design, direction • Architecture describes what a Shibboleth implementation should do • Code is “AN” implementation of the architecture • In the code, some logical architectural components combined; others don’t exist; some exist in strange form • RM functionality exists in several places

29. Shibboleth as Implemented by Internet2 • Java IdP, C++ SP for Apache and IIS, Java SP in development • Extremely flexible and modular • Built on included OpenSAML; supports SAML 1.0, 1.1, and will support 2.0 • Supports SAML Browser/POST profile • SAML Artifact Profile will be supported in v1.3 • Other implementations exist

30. Key Concepts • SAML • Attributes in an Inter-Realm Context • Metadata and ProviderIDs • Credentials and Relying Parties • Attribute Release Policies (ARP’s) • Attribute Acceptance Policies (AAP’s)

31. SAML • Security Assertion Markup Language • Codified by OASIS’ SSTC with participation from MACE and other bodies • Defines XML schema for Authentication and Attribute Assertions, Queries and Responses, and profiles of use like Web SSO • Defines bindings to protocols for transport • Many vendor implementations support SAML 1.x • v2.0 expands to include concepts from Liberty Alliance and Shibboleth

32. Shibboleth vs SAML • Shibboleth is a profile of SAML • Shibboleth Architecture document describes how Shibboleth uses SAML • Shibboleth extends SAML, defining a new NameIdentifier (the Handle) • The Shibboleth implementation includes a trust fabric implementation based on PKI • The Shibboleth implementation includes a framework and metadata for identifying IdPs and SPs • The Shibboleth implementation includes a mechanism (ARPs) to manage the release of attribute information to SPs

33. Attributes in an Inter-Realm Context • Provided by IdP, validated and evaluated by SP • Converted to SAML form for transport • Federations guide usage of common attributes and values, e.g. eduPerson, courseID • Others defined within bilateral relationships • Who can assert which attributes? • What level of assurance is there that this data is accurate?

34. Metadata and ProviderIDs • A ProviderID is the basic atom of inter-realm policy and trust; the molecule is the enterprise • URI (urn:mace:inqueue:supervillain.edu, or https://dspace.osu.edu/shibboleth) • Each SP or IdP deployment may encompass multiple logical "providers" • XML-based "metadata" about providers within a federation is exchanged to configure and secure interactions • Must be carefully defined; defines distributed use of enterprise Shibboleth infrastructure • Care must be taken when defining ProviderIDs for single or multiple federation use

35. Credentials and Relying Parties • Metadata includes references to (or actual) the credentials used by providers within a federation to sign XML or create SSL connections • A Relying Party is the other end in a transaction, and may represent an individual provider or a collection of providers • Configuration of software enables decisions about behavior and credentials to be made per-relying-party, allowing flexibility

36. Attribute Release Policies (ARPs) • Policies at the IdP governing the release of attributes to various service providers (based on an SP's ProviderID, which is its "name") • ARPs limit attributes released to a relying party on a global or per-user basis • Can match individual SPs or regular-expression-based matches; supports both positive and negative attribute rules

37. Attribute Acceptance Policies (AAPs) • AAPs filter received attributes before they are used by applications or as part of access control decisions • Also enforces privacy by limiting information available in the Shibboleth runtime to applications based on what they need • Partial answer to who can assert which attributes • Collectively define the set of attributes available to the resource manager to make access decisions

38. The Attribute Exchange • AA • Finds all relevant ARPs, based on relying party’s ProviderID • Computes “effective ARP” • Obtains attribute values for this user from the Attribute Repository • Uses effective ARP to filter values • SAML transports attributes; processed by AAPs • Together, help define total set of information in a Shibboleth exchange

39. Typical Shibboleth + Application Deploy Scenarios • Everything behind the front door is protected • Web server does Authn + Authz; application serves data • Existing Session/Authn infrastructure • Only "front door/login" protected via Shib, application session created as a result, with subsequent requests tied to application session • One URL for all resources; parameters specify which resource is desired • Application does Authz processing after identifying desired resource • One URL for all resources; parameters specify which resource is desired; some resource is public and some is protected • Application does Authz processing after identifying desired resource

40. The InCommon Federation

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

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

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

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

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

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

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

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

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

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