1. Internet2 Shibboleth Project TERENA Networking Conference 2002, Limerick, Ireland RL “Bob” Morgan, Washington Steven Carmody, Brown Scott Cantor, Ohio State Marlena Erdos, IBM/Tivoli Michael Gettes, Georgetown Keith Hazelton, Wisconsin David Wasley, UCOP... and many more Ken Klingenstein, Director Internet2 Middleware Initiative

2. Outline Background – I2 Middleware Work; Shibboleth Goals, Assumptions, Timelines, Related Works. Shibboleth Basics – how it works; demos. Technical Topics •Shibboleth Technical Architecture •User and Institutional Attribute Authorities, Resource Managers Applications and Shibboleth – EBSCO, NSDL, Meteor, WebAssign Non-technical topics •Software licensing and maintenance Marketplace adoption – higher ed, GXA, Liberty, etc. •Club Shib bylaws and operations Wrap-up – what it buys, and what it costs… http://middleware.internet2.edu/shibboleth

3. Interrealm authorization: current approaches Lots of ad hoc, non-scalable, difficult to maintain, and restrictive approaches: •Single ID and shared passwords are distributed, perhaps widely, presenting significant accountability risks. Content providers limit access by IP address, leaving campus users on DSL/cable modems at home frustrated… •Campuses operate proxy services or VPNs that inconvenience users and present performance bottlenecks. •Sometimes campuses must load user identities into vendor databases, incurring additional cost, stale data, and potential privacy violations. Users get new userids and passwords in each realm, incurring huhge overhead (and they often set all their passwords to be the same…)

4. Shibboleth Basics “Interrealm Attribute-based Authorization for Web Services” •An initiative to develop an architecture, policy framework, and practical technologies to support inter-institutional sharing of resources •Based on a federated administration trust framework •Provides the secure exchange of interoperable attributes which can be used in access control decisions •Controlled dissemination of attribute information, based on administrative defaults and user preferences •Shifts the model from passive privacy towards active privacy •Developed with vendor participation - IBM/Tivoli •Standards Alignment - OASIS/SAML •Open solution (protocols and messages documented rfc-style, open source implementation available)

5. Founding assumptions Federated Administration – Focus on inter-institutional issues, with each enterprise responsible for authentication and assertion of attributes. Create mechanisms for lightweight federation operations. Disturb as little of the existing campus infrastructure as possible but encourage good campus behaviors Build a system that supports security but does not degrade privacy. Leverage vendor and standards activity wherever possible (OASIS/SAML http://www.oasis-open.org/committees/security/ ), but recognize distinctive business needs. Work with widespread campus technologies. Learn through doing – There is very little experience with systems that allow users to manage the release of attribute information. Create a marketplace and reference implementations.

6. Federated Administration Leverage local authentication mechanisms (UID/PW to PKI) Origin Site •Must have joined the appropriate communities May have created “reasonable” default attribute release policies •Responsible for initial identification and registration of users •Responsible for managing attributes (eg Affiliation) •Responsible for Authenticating users prior to resource access Browser User •Only needs to know the name of his/her origin domain •May have created specific attribute release policies Target Resource Manager •Must have joined the appropriate communities •Manage policies governing access to the resource

7. Rethinking Privacy Passive privacy - The current approach. A user passes identity to the target, and then worries about the target’s privacy policy. To comply with privacy, targets have significant regulatory requirements. The user has no control, and no responsibility. And no one is happy... Active privacy - A new approach. A user (through their security domain) can release the attributes to the target that are appropriate and necessary. If the attributes are personally identifiable. If the attributes are personally identifiable, the user decides whether to release them. The user has control, along with commensurate responsibility. All parties are happy

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

9. 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-campus - crossing political boundaries • Controlled by unique identifiers (e.g. name) 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 while respecting the content provider’s need for accountability.

10. Milestones Project formation - Feb 2000 Stone Soup Process - began late summer 2000 with Tivoli commitment (w/Marlena Erdos), project leadership in fall 2000 (w/Steven Carmody), bi-weekly calls to develop scenario, requirements and architecture. Linkages to SAML established Dec 2000 (consistent architecture and distinguished territory) Architecture and protocol completion - Aug 2001 Design - Oct 2001 Coding began - Nov 2001 Alpha release – April 2002 (!)

11. Roll-out plan Three coding teams: CMU - origin; IBM/Tivoli - target; OSU - libraries Alpha code – available now Alpha pilots – April - June Beta code and beta pilots – June 1 - Sept 1 Release September 1 with Apache/modified BSD license Internet2 to operate CVS, bug tracking, etc.

12. Applications and Shibboleth – Currently working with: •NSDL (National Science Digital Library) •EBSCO (and other commercial information providers) •Meteor (Student Loan System) •WebAssign (Web Based Testing, Physics and Chemistry)

13. Shibboleth: How It Works Technical Components Demo

14. Technical Components Origin Site •Handle Server •Attribute Authority Target Site •SHIRE •SHAR •WAYF •Resource Manager Existing assumed components: for origins - Campus directory or attribute store; Web-ISO for targets - web servers and resource managers

15. Go to Target, SHIRE Destination site component responsible for context/session establishment Session establishment will commonly rely on traditional techniques (i.e. cookies). With no session in place, the SHIRE knows nothing about the user, so must either ask directly (SHIRE==WAYF) or redirect the user to a location that will ask on its behalf (SHIRE!=WAYF)

16. WAYF Where are You From? The WAYF is the transition point from destination to origin site HS when users contact a destination first. The Club’s Registry provides the WAYF with a list of members, and their Handle Servers Users can respond to the WAYF by indicating in “colloquial” fashion which institution can authenticate them. The WAYF will determine the URL of the appropriate HS based on the user’s input.

17. Handle Server Works with AA and local Web ISO system (authentication) to associate a query handle with an authenticated browser user and generate a signed assertion Performs its work in response to an Attribute Query Handle Request (currently an unauthenticated HTTP GET) Triggers local campus authentication system Generates a Handle “Remembers” mapping from Handle to specific user Sends Assertion with Handle to SHIRE

18. SHIRE Indexical Reference Establisher The SHIRE accepts and validates an assertion from a HS (Registry provides list of club members, their speakers, and associated cert’s) Associates the incoming handle with the session it creates. Passes control to the SHAR

19. SHAR Attribute Requester A SHAR makes attribute requests using the handle given it by the SHIRE.

20. Attribute Authority Receives Attribute Query Messages (AQM) from SHAR; returns Attribute Response Message (ARM) •Finds ARPs matching target •Determines which attributes and values to release Provides UI for specification and management of Attribute Release Policies (ARPs) Not a directory, but works with institutional directories and databases to aggregate and export attributes in a controlled fashion

21. SHAR Attribute Requester Upon receiving a response (AQR), the SHAR… …authenticates the response ( (Registry provides list of club members, their speakers, and associated cert’s) • The attribute assertion contains the name of the origin site (eg brown.edu) …extracts the attributes …checks attribute acceptance • e.g. can an AA at MIT issue attributes for Harvard?

22. Resource Manager Accepts Attributes from the SHAR Compares supplied Attributes against Policy associated with requested resource Grants/Denies access

23. Establishing a User Context

24. Getting Attributes and Determining Access

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

26. Authorization Attributes Typical Attributes in the Higher Ed Community Affiliation EPPN Entitlement OrganizationalUnit EnrolledCourse “active member of the community” identity An agreed upon opaque string Department Opaque course identifier Member@washington.edu gettes@georgetown.edu Urn:mace:infovendor:contract1234 Economics Department Physics 201

27. Non-technical Issues Software licensing and maintenance Marketplace adoption – higher ed, GXA, Liberty, etc. Trust Models and Federations Club Shib bylaws and operations

28. Software licensing and maintenance Two products at this point will be licensed and maintained: OpenSAML – a set of libraries to package,sign and unpack,verify SAML assertions, at opensaml.org Shibboleth – an open source and development environment for Shibboleth, attribute authorities, resource managers, etc. Both will operate under modified BSD licensing (see drafts at http://www.internet2.edu/members/html/intellectualproperty.html ) http://www.internet2.edu/members/html/intellectualproperty.html Internet2 and/or Club Shib membership may provide ongoing enhancements.

29. Marketplace issues Federation oriented marketplace new and very active – OASIS and SAML standards processes Liberty Alliance Microsoft.Net and GXA Shibboleth Shibboleth and PKI are complementary The embedded base of work-arounds create inertia, but middleware development is active on many campuses right now Build-on projects – digital rights management, K-12, etc. Promotion and adoption process

30. SAML: Security Assertion Markup Language Standards for XML-based authentication/authorization assertion formats, basic request-response protocol Designed to support interop among web single-sign products (Netegrity, RSA, IBM, Entrust, many others) OASIS technical committee formed in Jan 2001; difficult but successful standards process Used Shibboleth as one of several scenarios to design SAML 1.0 specs finished May 28 2002, awaiting OASIS ratification Interop testing under way among many vendors Spec punts on many issues, from communities to privacy

31. Shibboleth and SAML SAML is specifying a format and a means to exchange authentication and authorization assertions Shibboleth builds a general purpose public infrastructure around SAML by •developing user-navigation services, •standards to manage the exchange of attributes, •standard sets of attributes to be exchanged, and •infrastructure and user tools to preserve and manage privacy. •supporting groups using a common policy model; a scaleable solution to common needs SAML is creating a middleware equivalent of an IP address. Shibboleth adds services equivalent to DNS, routing, etc, to create a middleware equivalent of the Internet.

32. Liberty, Microsoft, etc Liberty (www.projectliberty.org)www.projectliberty.org Sun, American Express, Citibank, United, Nokia … federated identity and privacy management technology uncertain; partnership is complex Microsoft GXA with derivative products (WSDL, etc.) Passport and, once, Hailstorm partial partnership with IBM AOL Magic Carpet

33. Shibboleth and PKI Complementary technologies Technically: • Shibboleth leverages existing campus authentication processes (and can use end-entity certificates for this process) • Shibboleth uses PKI to implement a multi-domain trust model Shibboleth’s primary use is for authorization and privacy PKI’s primary use is establishing identity across domains • PKI can use Shibboleth to achieve privacy and authorization. Policy: • Shibboleth establishes a collaborative trust model (flexible, quick, privacy- enabled, etc.) • PKI establishes a legal trust model (binding, hierarchical, formal, etc.).

34. Federations and Club Shib Trust model continuum Creating and managing federations Club Shib

35. The Continuum of Trust Collaborative trust at one end… •can I videoconference with you? •you can look at my calendar •You can join this computer science workgroup and edit this computing code •Students in course Physics 201 @ Brown can access this on-line sensor •Members of the UWash community can access this licensed resource Legal trust at the other end… •Sign this document, and guarantee that what was signed was what I saw •Encrypt this file and save it •Identifiy yourself to this high security area

36. Dimensions of the Trust Continuum Collaborative trust handshake consequences of breaking trust more political (ostracism, shame, etc.) fluid (additions and deletions frequent) shorter term structures tend to clubs and federations privacy issues more user-based Legal trust contractual consequences of breaking trust more financial (liabilities, fines and penalties, indemnification, etc.) more static (legal process time frames) longer term (justify the overhead) tends to hierarchies and bridges privacy issues more laws and rules

37. The Trust Continuum, Applications and their Users Applications and their user community must decide where their requirements fit on the trust continuum. Some apps can only be done at one end of the continuum, and that might suggest a particular technical approach. Many applications fit somewhere in the middle and the user communities (those that trust each other) need to select a approach that works for them.

38. Shibboleth (and SAML) Federations A group of organizations (universities, corporations, content providers, etc.) who agree to provide access to resources using the SAML/Shibboleth protocols. In doing so they agree to abide by common sets of rules. The required rules and functions include: •A registry to process applications and administer operations •A set of best practices on associated technical issues, typically involving security and attribute management •A set of agreements or best practices on policies and business rules governing the exchange and use of attributes. •The set of attributes that are regularly exchanged (syntax and semantics). A mechanism (WAYF) to identify a user’s security domains

39. Club Shib 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.) Club 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

40. Club Shib 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

41. Club Shib Application Application must include appropriate technical details: certs, org names, hs address, people contacts, etc. Origin applicants must provide attribute management statement URL (see http://middleware.internet2.edu/shibboleth/samplepolicy/);http://middleware.internet2.edu/shibboleth/samplepolicy/ Must include eligibility, identification, authentication, and reuse information. Target applicants must provide attribute handling statement.

42. The benefits and costs Institutions can deploy a single interrealm authentication and authorization approach that can work for library, research and instructional needs. Vendors can get their toes (big toe) into the web services water A marketplace can be shaped that does not degrade privacy needlessly A new widely used open-source web infrastructure can be created. Institutions need to get their management processes aligned to support middleware Middleware components need to be installed.

43. The Value of Shibboleth …. Institutions can deploy a single interrealm authentication and authorization approach that can work for library, research and instructional needs. Enables greater granularity in access control policy Part of the solution to the “higher degree of integration” problem Establishes institutions as Identity Service Providers in upcoming competitive market Promotes inter-institutional, attribute-based approach for institutional applications and services