Welcome to CAMP Shibboleth

1. Welcome to CAMP Shibboleth Ken Klingenstein, Director, Internet2 Middleware Initiative

2. Overview • Workshop Context • A word from our sponsors • A word about NMI-EDIT • A flashback to NSFnet • A brief history of Shib • Outcomes 2

3. CAMP Themes: Shibboleth and Federations • Shibboleth software deployment for both institutional resource providers and users • Case studies across higher education of how institutions are using the software • Emerging policy and campus requirements for participating in federations • Future direction of Shibboleth architecture and international federation work • Exploration of the impact of this new environment on campus constituents 3

4. CAMP Schedule and Tracks • Monday – Exploration of case studies • Tuesday – Details of implementation – 3 Tracks • Management track – federation and policy issues • Technical track – intersection of federations and the software and advanced technical issues • Install Fest – hands-on assistance with installing the Shibboleth software 4

5. CAMP Schedule and Tracks • A Special Note on our First Install Fest • Focused on installing Shibboleth Identity Provider (Origin) Software, not the web server components it uses • Must have the web server software setup on a remote machine before the session starts • Session is full and we apologize for the space limitations!! • Thanks for your overwhelming interest and enthusiasm 5

6. CAMP Schedule and Tracks • Wednesday • Special Topics and Demos • The Future • Free Consulting 6

7. Have Questions? • Ann West 7

8. A Word From Our Sponsors • National Science Foundation’s Middleware Initiative (NMI) • NMI – Enterprise Desktop Integration Technologies (EDIT) Consortium • Internet2 – primary on grant and research • EDUCAUSE – primary on outreach • Southeastern Universities Research Association (SURA) – primary on NMI Integration Testbed 8

9. NMI-EDIT: Goals • Create a ubiquitous common, persistent and robust core middleware infrastructure for the R&E community • Provide tools and services (e.g. registries, bridge PKI components, schemas, root directories) to support inter-institutional and inter-realm collaborations 9

10. NMI-EDIT: Core Middleware Scope • Identity and Identifiers – namespaces, identifier crosswalks, real world levels of assurance • Authentication – campus technologies and policies, inter-realm interoperability via PKI, Kerberos • Directories – enterprise directory services architectures and tools, standard object classes, inter-realm and registry services • Authorization – permissions and access controls, delegation, privacy management • Integration Activities – common management tools, use of virtual, federated and hierarchical organizations 10

11. A Map of Middleware Land 11

12. NMI-EDIT: Strategic Direction • Overall technical direction set by MACE • Middleware Architecture Committee for Education (MACE) • Bob Morgan, University of Washington, Chair • Campus IT architects and representatives from Grids and International Communities • Directions set via • NSF and NMI management team • Internet2 Network Planning and Policy Advisory Council • PKI and Directory Technical Advisory Boards • Internet2 members 12

13. 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 – RL “Bob” Morgan (UW) Chair, Tom Barton (Chicago), Scott Cantor (Ohio State), Steven Carmody (Brown), Michael Gettes (Duke), 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), Diego Lopez (Spain) • Creates working groups in major areas, including directories, interrealm access control, PKI, video, P2P, etc. • Works via conference calls, emails, occasional serendipitous in-person meetings... 13

14. Middleware Axioms • Work the core areas • Focus on support for collaboration • Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions • Develop a consistent directory infrastructure within R&E • Provide security while not degrading privacy. • Foster interrealm trust fabrics: federations and virtual organizations • Leverage campus expertise and build rough consensus • Support for heterogeneity and open standards • Influence the marketplace; develop where necessary 14

15. Sample NMI-EDIT Process: Directories • MACE-DIR Working Group • Prioritize needed materials • Establish subgroups • revision of basic documents (LDAP Recipe) • new best practices in groups and metadirectories • standards development for eduPerson 1.5 and eduOrg 1.0 • Workin enhanced IETF approach: scenarios, requirements, architectures, recommended standards stages • Announce deliverables; start input and conference call review/feedback processes; reconvene work groups as needed • Process schedule and requirements • 4-6 months for completion, depending on product • 6-8 primary contributors • 15-50 schools participating 15

16. NMI-EDIT: Participants • Higher Ed • 15-20 leadership institutions, with 50 more campuses represented as members of working groups; readership around 2000 institutions • Corporate • (IBM/Metamerge, Microsoft, SUN, Liberty Alliance, DST, MitreTek, Radvision, Polycom, EBSCO, Elsevier, OCLC, Baltimore Technologies) • Government • NSF, NIST, NIH, Federal CIO Council • International • Terena, JISC, REDIRIS, AARnet, SWITCH 16

17. A flashback to NSFnet • Keep it simple and solve real problems • Make a marketplace • Stay low for as long as you can… • Be prepared to travel 17

18. Brief history of Shib • The model • The development process • The fateful bottle of wine… • The early vision • Refining the architecture and working with IBM • The many miracles 18

19. Unified field theory of Trust • Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc. • Passports, drivers licenses • Future is typically PKI oriented • Federated enterprise-based; leverages one’s security domain; often role-based • Enterprise does authentication and attributes • Federations of enterprises exchange assertions (identity and attributes) • Peer to peer trust; ad hoc, small locus personal trust • A large part of our non-networked lives • New technology approaches to bring this into the electronic world. • Distinguishing P2P apps arch from P2P trust • Virtual organizations cross-stitch across one of the above 19

20. The Model:Enterprises and Federation • Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so • Build consistent campus and enterprise middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then • Federate those enterprise deployments, using the outward facing campus infrastructure, with interrealm attribute transports, trust services, etc. and then • Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, and then, going forward • Create tools and templates that support the management and collaboration of virtual organizations by building on the federated campus infrastructures. 20

21. Federated administration VO VO O T A CM O T CM A Campus 1 Campus 2 T T T Federation 21

22. The development process • The fateful bottle of wine… • The early vision • Refining the architecture and working with IBM • The many miracles 22

23. The Many Miracles • A core group dreamed it… • Then Scott came along • Then Walter came along • Then Mark and David and Derek and so many others came along… 23