Shibboleth Update Advanced CAMP 7/31/02

1. Shibboleth UpdateAdvanced CAMP7/31/02 http://middleware.internet2.edu/shibboleth/ RL “Bob” Morgan, Washington Steven Carmody, Brown Scott Cantor, Ohio State Marlena Erdos, IBM/Tivoli Michael Gettes, Georgetown Keith Hazelton, Wisconsin David Wasley, UCOP The CMU programming team Ken Klingenstein, Director Internet2 Middleware Initiative

2. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status - Development • Current Status - Rollout • Demo • Next Steps • What Does it Take for a Campus to Install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

3. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status • Demo • Next Steps • What Does it Take for a Campus to Install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

4. Quick Definition/Architecture Refresh/ Review • Background, Motivation • High Level Architecture • Policy and Trust

5. What is Shibboleth? What is Shibboleth? An initiative to develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services A project delivering an open source implementation of the architecture and framework

6. What is Shibboleth? • A system... • …with an emphasis on privacy • users control release of their attributes • …based on open standards (SAML) and available in open source form • …built on “federated administration”

7. Example Scenarios • A member of the campus community accessing a licensed library resource • Students enrolled in a course across multiple universities accessing class materials and Learning Mgmt Systems • Research workgroups sharing controlled resources (the original web) • Intra-university information access

8. Why Shibboleth? • Growing interest in collaboration and resource sharing among institutions • Better security tools will make collaboration more “painless” and more secure • Current "solutions" are primitive; we can do better today and without local overhaul

9. Why Shibboleth?Federated Administration • Users registered only at their “home” or “origin” institution • Flexibly partitions responsibility, policy, technology, and trust • Authorization information sent, instead of authentication information • when possible, use groups instead of people on ACLs • identity information still available for auditing and for applications that require it

10. Why Shibboleth?Privacy • Higher Ed has privacy obligations • In US, “FERPA” requires permission for release of most personal identification information; encourages least privilege in information access • General interest and concern for privacy is growing • Shibboleth has active (vs. passive) privacy provisions “built in”

11. What is Shibboleth?Deliverables • A partially-complete open-source implementation of SAML (OpenSAML) • An open-source implementation of the Shibboleth architecture on top of OpenSAML • Policies, trust infrastructure, and supporting material to enable deployment within interested communities, leveraging existing work when possible (e.g. eduPerson)

12. Quick Definition/Architecture Refresh/ Review • Background, Motivation • High Level Architecture • Policy and Trust

13. High Level Architecture • Destination and origin site collaborate to provide a privacy-preserving “context” for Shibboleth users • Origin site authenticates user • Destination site requests attributes about user directly from origin site • Users (and organizations) can control what attributes are released

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. High Level Architecture

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

17. AuthorizationAttributes • Typical Attributes in the Higher Ed Community

18. Shibboleth and PKI • Shibboleth will establish a lightweight PKI between sites and servers to secure itself. • Shibboleth fully supports the use of certificates to authenticate users. • Shibboleth follow-on work will fully support the use of certificates by target sites directly, provided the necessary profile work is undertaken.

19. Quick Definition/Architecture Refresh/ Review • Background, Motivation • High Level Architecture • Policy and Trust

20. Policy and Trust • SAML and the Shibboleth architecture leave “tough” questions about policy and trust to implementers and deployers. • Communities of sites that want to interoperate will establish federations with common policies and trust models

21. Federations (Circles of Trust) • Communities must define (for example): • attribute vocabulary, syntax, and usage • expectations in areas like user identification and authentication, account policies • a trust model for securing the system • Internet2/MACE is forming one such federation (informally known as “Club Shib”) by creating policy documents and infrastructure for higher education sites and those with which we do business.

22. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status • Demo • Next Steps • What Does it Take for a Campus to install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

23. Current Status • Architecture about to enter final call • Policy documents being drafted • Programming divided among Carnegie Mellon, Ohio State, and additional contractors • OpenSAML Beta-1 available now • Shibboleth Alpha-2 available to selected sites early July, wider distribution soon (10-20 projects)

24. Current Status • Call for participation went out to campuses in late-June for pilot with commercial content providers (EBSCO, Elsevier, sfx) • Several European Higher Ed systems evaluating Shib for use country-wide • First Shibbolized application has gone production. • Production version of Shibboleth expected by October, with the goal of inclusion in the second NMI release

25. Currently working with • NSDL (National Science Digital Library) • Commercial Content Providers (EBSCO, Elsevier, sfx, OCLC) • Meteor (Student Loan System) • WebAssign (Web Based Testing, Physics and Chemistry)

26. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status • Demo • Next Steps • What Does it Take for a Campus to Install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

27. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status - Development • Current Status - Rollout • Demo • Next Steps • What Does it Take for a Campus to install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

28. Next Steps • Wider alpha Deployment, for verification and testing • Complete v1 implementation • Identify Other key applications • Gain experience with federation • What does it mean to “manage attribute release”? • Shibbolizing other applications?

29. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status • Demo • Next Steps • What Does it Take for a Campus to Install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

30. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status • Demo • Next Steps • What Does it Take for a Campus to Install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

31. Policy and Trust:“Club Shib” • A foundation on which to build: • an initial set of attributes based on eduPerson but fully supporting bilateral arrangements • a simple PKI suitable for “collaborative trust” • a central registry of information about participating sites and their local account practices • basic rules governing membership, usage of attributes, and layering of additional policies • A low barrier to entry for both schools and information providers

32. Campus Account Practices of Interest to Club Members • Initial identification/password assignment process for accounts • Authentication mechanisms for account use • Policy on the reuse of account names • Business logic for key attributes like affiliation, as the need surfaces Current intent is descriptive, not prescriptive.

33. Discussion outline • Quick Definition/Architecture Refresh/ Review • Current Status - Development • Current Status - Rollout • Demo • Next Steps • What Does it Take for a Campus to install Shib? • Installation and plumbing • Joining the Club • Here's how you can get involved! • Questions/ Discussion.

34. Here's how you can get involved! • Let us know you’re interested • Join the email lists • Identify problems in your environment where Shib could provide value • Respond to the CFP • Talk to us this week!

35. THE END • Acknowledgements: • Design Team: David Wasley U of C; RL ‘Bob’ Morgan U of Washington; Keith Hazelton U of Wisconsin (Madison);Marlena Erdos IBM/Tivoli; Steven Carmody Brown; Scott Cantor Ohio State • Important Contributions from: Ken Klingenstein (I2); Michael Gettes Georgeton, Scott Fullerton (Madison)

37. Questions, Discussion…. • .