JA-SIG Winter Conference 2002 Orlando, Florida

1. National Science FoundationMiddleware Initiative(NMI) JA-SIGWinter Conference 2002Orlando, Florida Michael R Gettes Principal Technologist Georgetown University gettes@georgetown.edu

2. NSF Middleware Initiative • Purpose • To design, develop, deploy and support a set of reusable, expandable set of middleware functions and services that benefit applications in a networked environment

3. NMI Organization • GRIDS Center • ISI, NCSA, U Chicago, UCSD & U Wisconsin • EDIT Team (Enterprise and Desktop Integration Technologies) • EDUCAUSE, Internet2 & SURA Core NMI Team Grants for R & D • Year 1 -- 9 grants • Year 2 -- 9 grants

4. Experimental Software & research applications Early Implementations - GRID services, directories, authentication, etc Research & Education Early Adopters MiddlewareTestbeds - experimental, Beta, scaling & “hardening” Consensus - disciplines - communities - industries Dissemination & Support Middleware deployment NMI Process

5. First Deliverables: NMI Release 1 • Software • (Globus, Condor, Network Weather Service, KX.509, CPM, Pubcookie) • Object Classes • (eduPerson, eduOrg, commObject) • White Papers (Shibboleth, video directories, etc) • Best Practices (Directories, LDAP) • Policies (campus certificates, account management) • Services (certificate profile registry) www.nsf-middleware.org

6. GRIDS Center, Part of the NSF Middleware Initiative • One of two NMI teams, the GRIDS Center (Grid Research, Integration, Development & Support) • In late 2001, GRIDS created to: • Define, develop, deploy, and support an integrated national middleware infrastructure for 21st Century S&E • Create robust, tested, packaged, & documented middleware for S&E, including large NSF projects (e.g., NEES, GriPhyN, TeraGrid) • Work with middleware research community to evolve architecture & integrate other components • Provide dedicated operations capability for 24x7 support and monitoring of Grid infrastructure

7. Elements of Grid Computing • Resource sharing as a fundamental pursuit • Computers, storage, sensors, networks • Sharing is always conditional, based on issues of security, trust, policy, negotiation, payment, etc. • Coordinated problem solving • Beyond client-server: distributed data analysis, computation, collaboration, etc. • Dynamic, multi-institutional “virtual organizations” • Community overlays on classic org structures • Large or small, static or dynamic

8. Grid-Oriented Projects in eScience

9. Grid Applications • Science portals • Help scientists overcome steep learning curves of installing and using new software • Distributed computing • High-speed workstations and networks as aggregated computational resources • Large-scale data analysis • Computer-in-the-loop instrumentation • Grids permit quasi-real-time analysis of data from telescopes, synchrotrons, and electron microscopes • Collaborative work • Grids enable collaborative problem formulation, data analysis, and discussion

10. The 13.6 TF TeraGrid:Computing at 40 Gb/s Site Resources Site Resources 26 HPSS HPSS 4 24 External Networks External Networks 8 5 Caltech Argonne External Networks External Networks NCSA/PACI 8 TF 240 TB SDSC 4.1 TF 225 TB Site Resources Site Resources HPSS UniTree TeraGrid: NCSA, SDSC, Caltech, Argonne www.teragrid.org

11. Galaxy cluster size distribution Chimera Virtual Data System + iVDGL Data Grid (many CPUs) Sloan Digital Sky Survey Analysis Size distribution of galaxy clusters?

12. Grids and Industry • Grid computing has much in common with major industrial thrusts to decentralize (e.g., B2B, P2P, ASP, etc.) • Sharing issues are not adequately addressed by existing technologies • Companies like IBM, Platform Computing and Microsoft are now substantively involved with the open-source Grid community (e.g., OGSA, which combines Web services and Grid services)

13. NMI-EDIT: Goals • Much as at the network layer, create a ubiquitous common, persistent and robust core middleware infrastructure for the R&E community • In support of inter-institutional and inter-realm collaborations, provide tools and services (e.g. registries, bridge PKI components, root directories) as required

14. A Map of Middleware Land

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

16. NMI-EDIT: Organization • Overall technical direction set by MACE • Middleware Architecture Committee for Education (MACE) • 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

17. Sample NMI-EDIT Process (Directories ) • MACE-DIR Working Group prioritizes needed materials • Subgroups established: • revision of basic documents (LDAP Recipe) • new best practices in groups and metadirectories • standards development for eduPerson 1.5 and eduOrg 1.0 • Subgroups work in enhanced IETF approach: scenarios, requirements, architectures, recommended standards stages • Working group deliverables announced; input and conference call review/feedback processes start; work groups reconvene as needed • Process takes around 4-6 months, depending on product • 6-8 people drive the process with 15-50 schools participating

18. A Few Year-One NMI-EDIT Milestones • Sept 1, 2001 – Grant awarded • Oct 2001– eduPerson 1.0 finalized; outreach begins with multiple workshops • Jan 2002 – HEBCA tested; first CAMP workshop held • Feb 2002 – PKI Lite CP/CPS; e-Gov and Management and Leadership Best Practice Awards • April 2002 – Shibboleth alpha ships; NMI testbed selected; NIST/NIH PKI workshop • May 2002 – NMI release, with eduPerson 1.5, pubcookie, KX.509, groups and metadirectories, video white papers • June 2002 – affiliated directories begins; Base CAMP; testbed kickoff • July 2002 – Shibboleth alpha v 2 ships; Advanced CAMP • August 2002 – LDAP Analyzer testing begins; Shibboleth pilot-sites selected; Work with content providers begins • September 2002 – Grant renewed; supplemental grant awarded for outreach; Shibboleth beta ships • October 2002 -- NMI Release 2 (see itemized list; www.nsf-middleware.org)

19. NMI-EDIT: Release 1 Deliverables • Software KX.509 and KCA, Certificate Profile Maker, Pubcookie • Object Classes eduPerson 1.0, eduPerson 1.5, eduOrg 1.0, commObject 1.0 • Service Certificate Profile Registry

20. NMI-EDIT: Release 1 Deliverables • Conventions and Practices • Practices in Directory Groups 1.0, LDAP Recipe 2.0 • Metadirectory Practices for the Enterprise Directory in Higher Education 1.0 • White Papers • Shibboleth Architecture v5 • Policies • Campus Certificate Policy for use at the Higher Education Bridge Certificate Authority (HEBCA) • Lightweight Campus Certificate Policy and Practice Statement (PKI-Lite) • Sample Campus Account Management Policy

21. NMI-EDIT: Release 1 Deliverables • Works in Progress • Role of Directories in Video-on-Demand • Resource Discovery for Videoconferencing • Directory Services Architecture for Video and Voice Conferencing over IP (commObject)

22. NMI-EDIT: Release 2 New/Revised Deliverables • Software  Programs and Libraries • OpenSAML 1.0                • Shibboleth 1.0                • Pubcookie 3.0 Directory Schemas • eduPerson             • eduOrg

23. NMI-EDIT: Release 2 New/Revised Deliverables • Conventions and Practices • LDAP Recipe        • Metadirectory Practices for Enterprise Directories     • Practices in Directory Groups • Architectures • Inter-domain Data Exchange (Draft)        • Services • LDAP Analyzer

24. The pieces fit together… Campus infrastructure Name space, identifiers, directories Enterprise authentication and authorization Inter-realm infrastructure edu object classes Exchange of attributes Inter-realm Upperware Grids Digital libraries Video

25. A Campus Directory Architecture border directory metadirectory Enterprise applications dir enterprise directory departmental directories OS directories (MS, Novell, etc) directory database registries source systems

26. Shibboleth Updatemiddleware.internet2.edu/shibboleth Steven Carmbody, Brown University Project Leader, Shibboleth Michael R. Gettes, Georgetown University

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

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

29. Shibboleth Architecture

30. Shibboleth Components

31. local authn server - assumed part of the campus environment web sso server - typically works with local authn service to provide web single sign-on resource manager proxy, resource manager - may serve as control points for actual web page access attribute authority - assembles/disassembles/validates signed XML objects using attribute repository and policy tables attribute repository - an LDAP directory, or roles database or…. Where are you from service - one possible way to direct external users to their own local authn service attribute mapper - converts user entitlements into local authorization values PDP - policy decision points - decide if user attributes meet authorization requirements SHAR - Shibboleth Attribute Requestor - used by target to request user attributes Descriptions of services

32. Shibboleth Flows Draft

33. Shibboleth Architecture -- Managing Trust • TRUST Shib engine Attribute Server Target Web Server Browser Target Site Origin Site

34. Personal Privacy • Web Login Server provides a pseudononymous identity • An Attribute Authority releases Personal Information associated with that pseudnonymous identity to site X based on: • Site Defaults • Business Rules • User control • myAA • Filtered by • Contract provisions My AA Site Defaults Contact Provisions Browser User

35. Managing ARPs

36. The Liberty Alliancewww.project-liberty.org • Sun Microsystems, American Express, United Airlines, Nokia, MasterCard, AOL Time Warner, American Airlines, Bank of America, Cisco, France Telecom, Intuit, NTT DoCoMo, Verisign, Schlumberger, Sony … • Initiated in September 2001. • Protect Privacy, Federated Administration, Interoperability, Standards based but requires new technology, hard problems to solve, a Network Identity Service • Funny, doesn’t this stuff sound familiar?

37. Middleware Marketing

38. We all get Web SSO for Local Authentication and an Enterprise Authorization Framework with an Integrated Portal that will all work inter-institutionally! Shibboleth Inter-Realm AuthZ Local Web SSO Pressures Drivers of Vapor Convergence eduPerson 1.0 OKI/Web Authentication JA-SIG uPortal Authen

39. Middleware Inputs & Outputs Licensed Resources Embedded App Security Grids OKI JA-SIG & uPortal Inter-realm calendaring futures Shibboleth, eduPerson, Affiliated Dirs, etc. Enterprise authZ Campus Web SSO Enterprise Directory Enterprise Authentication Legacy Systems

40. www.internet2.edu