1. Intra- to Inter-institutional Use of Shibboleth Bruce Vincent, Stanford University June 28, 2006

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

3. Background Library and researcher motivations WebAuth and SU attributes Single campus and single user namespace

4. Identifying Stakeholders (and their motivations) Different for inter-institutional fed.s Entirely new level of risks and rewards Forces policy decisions

5. Stakeholders - Consumers Libraries (counterparties ready to go) Course Management Systems Researchers Administrators

6. Stakeholders - IT Infrastructure Groups Authentication and LDAP constituencies IdM providers: processes and mores PMO and support organizations

7. Stakeholders - IT Management Play the innovation card as needed Use buzz in trades and “expert” org.s Start small but scalable Sell the flexibility

8. Stakeholders - Policy Risk Management Information Privacy Officer Trademarks and Brands Office of General Counsel Internal Audit Information Security Officer

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

10. Picking a Sponsor Should be supportive and well placed Doesn’t hurt if they have a clue Make sure they understand their part

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

12. Bilateral Trusts Point to point links Realm trusts Extradition treaties

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

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

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

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

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

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

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