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. Resource WAYF Identity Provider Service Provider Web Site 1 ACS 3 2 HS 5 6 7 User DB Credentials 4 AR Handle 8 9 AA Attributes 10 Resource Manager 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

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

52. 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_co mpromise_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_F ederation_System_Technical_Reference_ver_0.41 –Document describing the CA.

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

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

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

56. Questions?

58. Simplified (Apache-based) Service Provider Architecture Origin Apache mod_ssl OpenSSL mod_shib AR WAYF MySQL Session DB

59. Shibboleth Service Provider Deploy Shibboleth is implemented as: –A set of plugins to Apache/IIS Handle “no authenticated session yet” situation Create authenticated sessions –Separate Attribute Requester (AR) process to maintain session info and offload most heavy lifting and SAML processing –(optional, for web farm deploys) database to hold session info –pluggable interfaces enable customization of most core behavior

60. Service Provider Request Mapping Architecture Web Server App Alpha Resource Requests App BetaApp Theta ProviderID FoopID Bar URL 1URL 2URL 3URL 4 Attribute Release, Policy Atom Sessions, Most Settings Webapps, pages, files, etc. AAPs and access decisions Lazy Session Initiation Externally Visible Resources

61. Applications, ProviderIDs, and Webapps Decouples internal applications and session boundaries from externally visible services Access controls can be defined at many granularities –Rules must be simple right now or enforced by application code examining HTTP headers –More complicated rules engines (XACML, SPOCP, complex XML booleans) under consideration/development Much of this should be hidden from users

62. Lazy Sessions Allows an application to call for a Shibboleth session when needed –Alternative to having web server/servlet container trigger session creation based on url path Invoked using a special redirect URL Rest of session establishment occurs as usual Session might expire, but application is responsible for dealing with that

63. Attribute Consumption and Use Exported via HTTP header variables Other information about the authenticated session available in header values Simple RM functionality included for Apache; using.htaccess, blocks, etc., require attribute values. Limited policy expression.

64. System Requirements Built successfully on OS X 10.3, Solaris 2.8+, Debian, RedHat 7.2, 7.3, 9, Fedora, Enterprise, Windows NT/2000/XP/2003 Binaries available for Windows; RPM’s available for Fedora and compatibles Apache 1.3 or 2.0 with SSL Support, or IIS 4.0+ OpenSSL Several prerequisite packages must be built from source or installed via RPM

65. Logging & Auditing All transactions can be logged; flat-file logging and log4j/log4cpp-based appenders both supported Multiple logging levels The user’s privacy is preserved; so is their identity Federation may help define practices: some information storage requirements for SPs may require co-operation from IdPs. Decision logic may be hidden at either the IdP or SP by constructive use of attributes

66. Deployment Resources http://shibboleth.internet2.edu http://inqueue.internet2.edu Origin: –http://shibboleth.internet2.edu/guides/deploy- guide-origin-1.2.1.htmlhttp://shibboleth.internet2.edu/guides/deploy- guide-origin-1.2.1.html –http://shibboleth.internet2.edu/guides/identity- provider-checklist.htmlhttp://shibboleth.internet2.edu/guides/identity- provider-checklist.html Target: –http://shibboleth.internet2.edu/guides/deploy- guide-target-1.2.1.htmlhttp://shibboleth.internet2.edu/guides/deploy- guide-target-1.2.1.html shibboleth-users@internet2.edu