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

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

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, s, occasional serendipitous in- person meetings...

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):Webster's Revised Unabridged Dictionary (1913)

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)

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)

Founding assumptions Leverage vendor and standards activity wherever possible (OASIS/SAML ), 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

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.

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

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

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)

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

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

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

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

Shibboleth Flows Draft

Detailed Component Descriptions Attribute Authority Handle Server SHIRE SHAR WAYF

Establishing a User Context

Getting Attributes and Determining Access

SHIRE Indexical Reference Establisher Destination site component responsible for context/session establishment When there is no active session, redirects browser user to the WAYF

WAYF Where 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!

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

SHIRE Indexical 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.

SHAR Attribute 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?

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

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

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

Shibboleth (and SAML) Communities of Interest (COI) (Ken Klingenstein)

D. Wasley’s PKI Puzzle

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

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

What Will it be Like to Use Shibboleth? Sample Browser Screens are available at: Actual user interface being designed by five higher ed Schools of Information

Use - Go Directly To Target

Use - Specify Origin Site

Use - Local Authentication

Use - Target Page Displayed!

Use - Local Navigation Site

Use - “in the background”

Use - Target Page Displayed!

Milestones Project formation - February 2000 Stone Soup Process - began late summer 2000 with Tivoli commitment (Marlena Erdos), project leadership fall (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

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

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

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

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

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 ??

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

Middleware Inputs & Outputs Grids JA-SIG & uPortalOKIInter-realmcalendaring Shibboleth, eduPerson, Affiliated Directories, etc. EnterpriseDirectoryEnterpriseAuthenticationLegacySystemsCampus web SSO futures EnterpriseauthZ LicensedResourcesEmbedded App Security Shibboleth, eduPerson, and everything else