Intra- to Inter-institutional Use of

ShibbolethBruce Vincent,

Stanford University

June 28, 2006

Agenda

• Background and Context• Identifying Stakeholders• Sponsorship• Various Approaches• Trusts and Federations• Running an Inter-institutional IdP and SP’s

Background

• Library and researcher motivations

• WebAuth and SU attributes

• Single campus and single user namespace

Identifying Stakeholders (and their motivations)

• Different for inter-institutional fed.s

• Entirely new level of risks and rewards

• Forces policy decisions

Stakeholders - Consumers

• Libraries (counterparties ready to go)

• Course Management Systems

• Researchers

• Administrators

Stakeholders - IT Infrastructure Groups

• Authentication and LDAP constituencies

• IdM providers: processes and mores

• PMO and support organizations

Stakeholders - IT Management

• Play the innovation card as needed

• Use buzz in trades and “expert” org.s

• Start small but scalable

• Sell the flexibility

Stakeholders - Policy

• Risk Management

• Information Privacy Officer

• Trademarks and Brands

• Office of General Counsel

• Internal Audit

• Information Security Officer

Policy Approach

• Try to leave existing policy intact• Make reasoned extensions where

needed• Understand the actual risks and explain

them objectively• Encourage the vetting process• Fix what the new models expose or

break

Picking a Sponsor

• Should be supportive and well placed

• Doesn’t hurt if they have a clue

• Make sure they understand their part

Approach on IT Infrastructure

• Leverage existing infrastructure

• If you’ve got it (and it works), use it

• Use existing public release policies for ARP’s

Bilateral Trusts

• Point to point links

• Realm trusts

• Extradition treaties

Multilateral Trusts and Federations

• Federations establish a trust context and basic language

• Shibboleth federations do not actively take part in authN

• Active exchanges are bilateral in Shibboleth federations

• Inter-library loans

What does a federation do?

• Registration authority tasks• Keeps list of federation members• WAYF service…for now• Keeps references to practice

statements and nomenclature• Keeps the legal agreements (e.g.

InCommon Participation Agreement)• Lives small

Critical Questions

• Is your institution ready to define digital trust relationships?

• Are you considering acting without formal support?

• Are most of your inter-institutional interactions likely to be bilateral?

• Are your staff and infrastructure ready? Does that matter?

• Are you actually likely to need a federation?

Running an IdP in an Inter-institutional Federation

• Operational considerations: high availability, backup&recovery, protection of certs, etc.

• Accommodation of “special” identifiers and TargetedID’s

• Default ARP takes on broader criticality• Federation protections are for the other guy• Being in a federation doesn’t automatically

give you access to anything

Running an SP in an inter-institutional federation

• Provisioning users and managing user data• Do other institutions need a contract to

access your SP?• Are your apps prepared for loooooong

identifiers?e.g. from 'swl' to 'b902a7ab35bda3efde7a4c01efbbf1c7a5247445@stanford.edu’

How’s it going on The Farm?

• Integrated Shibboleth IdP’s with WebAuth and culture

• Leveraged existing “visibility” attributes for user ARP’s

• Lobbied stakeholders successfully• Policy amendments on course• On time, under budget and beyond scope• Joined InCommon Federation• OCLC pilot running, others

Judges 12:6…an example of a security policy with teeth

• And it was so, that, when any of the fugitives of Ephraim said, Let me go over, the men of Gilead said unto him, Art thou an Ephraimite? If he said, Nay; then said they unto him, Say now Shibboleth; and he said Sibboleth; for he could not frame to pronounce it right: then they laid hold on him, and slew him at the fords of the Jordan. And there fell at that time of Ephraim forty and two thousand.