Shibboleth Update

1. Shibboleth Update RL “Bob” Morgan, Washington Steven Carmody, Brown Scott Cantor, Ohio State Marlena Erdos, IBM/Tivoli Michael Gettes, Georgetown Keith Hazelton, Wisconsin David Wasley, UCOP Ken Klingenstein, Director Internet2 Middleware Initiative

2. Outline • Background • What is Shibboleth? • Shibboleth Communities of Interest • Shibboleth and PKI • Shibboleth and SAML and WebSSO • Using Shibboleth • Shibboleth milestones • Roll-out plan and next steps • Getting ready • http://middleware.internet2.edu/shibboleth

3. MACE (Middleware Architecture Committee for Education) • Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher education • Membership - Bob Morgan (UW) Chair, Scott Cantor (Ohio State), Steven Carmody (Brown), Michael Gettes (Georgetown), Keith Hazelton (Wisconsin), Paul Hill (MIT), Jim Jokl (Virginia), Mark Poepping (CMU), Bruce Vincent (Stanford), David Wasley (California), Von Welch (Grid) • European members - Brian Gilmore (Edinburgh), Ton Verschuren (Netherlands) • Creates working groups in major areas, including directories, interrealm access control, PKI, medical issues, etc. • Works via conference calls, emails, occasional serendipitous in-person meetings...

4. Shibboleth • A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce sh, called the word sibboleth. See --Judges xii. • Hence, the criterion, test, or watchword of a party; a party cry or pet phrase. • - Webster's Revised Unabridged Dictionary (1913):

5. Shibboleth - What is it? • An initiative to develop an architecture, policy framework, and practical technologies to support inter-institutional sharing of resources • Will provide for 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 • Based on a federated administration trust framework • Vendor participation - IBM/Tivoli • Standards Alignment - OASIS/SAML • Open solution(protocols and messages documented rfc-style, open source implementation available)

6. Shibboleth - Why is it Needed? • Growing interest in collaboration and resource sharing among institutions • Provides ability to make access control decisions in a cross domain environment • Current approaches to problem (IP address filtering, identity matching, use of shared ids) have serious problems • Shibboleth will involve more than the architecture/implementation developed by the SAML participants (eg community-of-interest, privacy)

7. Founding assumptions • Leverage vendor and standards activity wherever possible (OASIS/SAML http://www.oasis-open.org/committees/security/ ), but recognize distinctive business needs. • Federated Administration • (Initially) disturb as little of the existing campus infrastructure as possible • Work with common, minimal authorization systems (eg htaccess) • Encourage good campus behaviors • 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

8. Stage 1 - Addressing Three 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) • 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.

9. Architectural Model • Browser User’s Origin Site Responsible for Authentication • Origin Site Entity Willing to Create and Sign Assertions • Set of assertions about the user (Attribute/value pairs) • User has control over disclosure • Identity optional • “active member of community”, “Associated with Course XYZ” • Target responsible for Authorization • Rules engine • Matches contents of assertions against ruleset associated with target object • Cross Domain Trust • Implemented in communities • Previously created between origin and target • Perhaps there is a contract (information providers..)

10. Affiliation EPPN Entitlement OrganizationalUnit EnrolledCourse “active member of the community” EPPN=gettes@georgetown.edu Urn:mace:infovendor:contract1234 Economics Department Physics 201 Authorization Attributes Typical Assertions in the Higher Ed Community

11. Implications of Shibboleth Design Choices • Support all 3 scenarios (not just the library problem) • -> need a mechanism to manage attribute release • Focus on Privacy Protection • Both sites and users need to manage attribute release • Assume Origin Site Authenticates User • Origin Site needs enterprise level authentication mechanism • Should have Web Single Signon system • Target Site Authorizes User • Need Trust Framework • Need agreement on syntax and semantics of attributes (eduPerson, custom agreements between pairs of sites)

12. Federated Administration • Origin Site • Must have joined the appropriate communities • May have created “reasonable” default attribute release policies • Responsible for Identifying and registering users • Responsible for Authenticating users • Browser User • May have created specific attribute release policies • Target Resource Manager • Manage policies governing access to the resource

13. Simple point-to-point model Service discovery service Policy enforcement point Policy enforcement point Policy enforcement points Authentication Service client target Protocols Enterprise LDAP directory Enterprise LDAP directory Attribute requestor Policv decision point Attribute authority Grid directory Video directory Video directory

14. Shibboleth ArchitectureConcepts - High Level Browser Pass content if user is allowed Target Web Server Authorization Phase Authentication Phase First Access - Unauthenticated Target Site Origin Site

15. Shibboleth ArchitectureConcepts (detail) Browser Target Web Server Authorization Phase Authentication Phase Success! Entitlements Attribute Server Ent Prompt Req Ent Second Access - Authenticated Auth OK Pass entitlements for authz decision Web Login Server Redirect User to Local Web Login Pass content if user is allowed Authentication Ask to Obtain Entitlements First Access - Unauthenticated Target Site Origin Site

16. Shibboleth Flows Draft

17. Detailed Component Descriptions • Attribute Authority • Handle Server • SHIRE • SHAR • WAYF

18. Establishing a User Context

19. Getting Attributesand Determining Access

20. SHIREIndexical Reference Establisher • Destination site component responsible for context/session establishment • When there is no active session, redirects browser user to the WAYF

21. WAYFWhere are You From? • The WAYF is the transition point from destination to origin site HS when users contact a destination first. • 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. • A variety of nasty semantic attacks lurk!

22. Handle Server • Works with AA and local Web ISO system 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) • AQHR contains • SHIRE URL for acceptance of response via HTTP POST • URL of desired resource/service at destination

23. SHIREIndexical Reference Establisher • Destination site component responsible for context/session establishment • Session establishment will commonly rely on traditional techniques (i.e. cookies). • The SHIRE accepts an assertion from a HS and associates the incoming handle with the session it creates.

24. SHARAttribute Requester • A SHAR makes attribute requests using the handle given it by the SHIRE. • Upon receiving a response (AQR), the SHAR… • …authenticates the response • …extracts the attributes • …checks attribute acceptance • e.g. can an AA at MIT issue attributes for Harvard?

25. Attribute Authority • Responds to Attribute Query Messages (AQM) from SHAR • Allows for specification and management of ARPs • Not a directory, but works with institutional directories and databases to aggregate and export attributes in a controlled fashion

26. IBM Interest • Provides “Federated” administrative model (as apposed to centralized or delegated) • Leaves administration of user and authenticating user to requester’s site • Leverages existing authentication/directory infrastructure • Privacy of requester preserved • Leverages SAML standard and will be one of its first “proof points” • Applies to B2B environments beyond current scope and definition

27. IBM and Tivoli’s commitment • IBM/Tivoli has been contributing to the architecture and design for over a year • IBM/Tivoli is committed to contributing to an open source implementation • Prototype underway • IBM/Tivoli is committed to continuing to drive ubiquitous Security standards • Shibb is based on existing standards where they exist • SAML, etc...

28. Shibboleth (and SAML) Communities of Interest (COI) • (Ken Klingenstein)

29. D. Wasley’s PKI Puzzle

30. Shibboleth and PKI • Complimentary infrastructures wrt technology and policy • 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.)

31. Shibboleth and SAML and WebISO • (R.L. “Bob” Morgan)

32. What Will it be Like to Use Shibboleth? • Sample Browser Screens are available at: • http://middleware.internet2.edu/shibboleth/mockups/index.html • Actual user interface being designed by five higher ed Schools of Information

33. Use - Go Directly To Target

34. Use - Specify Origin Site

35. Use - Local Authentication

36. Use - Target Page Displayed!

37. Use - Local Navigation Site

38. Use - “in the background”

39. Use - Target Page Displayed!

40. Milestones • Project formation - February 2000 Stone Soup • Process - began late summer 2000 with Tivoli commitment (Marlena Erdos), project leadershipfall (Steven Carmody), bi-weekly calls and scenario, requirements and architecture development • Linkages to SAML established December 2000 (consistent architecture and distinguished territory) • Architecture and protocol completion - Aug, 2001 • Design - Oct 2001 • Coding begins - Nov 2001

41. Roll-out plan • Basic coding stage through February 2002 • Alpha pilots Feb and March 2002 • Code rewrites March April • Beta pilots - April May • General release - June, 2002 • Release issues: • open-source license approach • distribution - Apache and other components • CVS, Bugtraq, and source/enhancement management

42. Coding stage • Three coding teams: • CMU - origin IBM/Tivoli - target OSU - libraries • Approach is to integrate hard-wired components and then progressively replace hard-wiring with code • Dec, Jan, Feb - finish coding, testing • End of february - packaging • End of Feb - March - deploy code to early pilot sites

43. Profile of Pilot Sites • Member of campus community accessing licensed resource • University hosting licensed DBs accessed from other universities • Talking to several commercial vendors (they need “their customers” asking for this functionality…) • Member of a course accessing remotely controlled resource • Web based testing • Clearinghouse for curriculum packages • Web based tools used in courses • Member of a workgroup accessing controlled resources • Multi-institution project teams

44. Some of the pilots • Webassign • Penn State • Univ of Delaware - Problem Based Learning Clearinghouse • EDINA (UK) • London School of Economics

45. Getting Ready • As a Target • think through web services architecture • examine contracts with origins for attribute requirements, business rules and marketing options • As an Origin • implement enterprise authentication infrastructure • implement eduPerson in enterprise directory • work with vendors to educate and take advantage • ??

46. Identity Services on One Slide Objectclass standards (e.g.eduperson, gridperson) Content Portals Shibboleth exchange of attributes Future PKI DODHE et al Grids et al Interrealm Learning Management Systems Security Domain Personal Portals Web services and servers WebISO Enterprise directory Campus authentication Future PKI

47. Shibboleth, eduPerson, and everything else Middleware Inputs & Outputs Licensed Resources Embedded App Security Grids OKI JA-SIG & uPortal Inter-realm calendaring futures Shibboleth, eduPerson, Affiliated Directories, etc. Enterprise authZ Campus web SSO Enterprise Directory Enterprise Authentication Legacy Systems