1. Middleware CAMP June 2002

2. Welcome Welcome to the Camp, I guess you all know why we're here. Tommy, by Pete Townsend, The Who We're not gonna take it Never did and never will We're not gonna take it Gonna break it, gonna shake it, let's forget it better still

3. Orientation Camp Goals, Schedules and Processes Acknowledgements NSF Middleware Initiative Basics of Middleware The Nature of the Work What Middleware Nirvana Looks Like Starting the consultant career development: know thy neighbor

4. CAMP Desiderata Interaction Awareness of the current developments in middleware in higher education Ways to motivate campus investments – benefits to instruction, science, administration, etc. A game plan for your campus, tuned to campus infrastructure Feedback mechanisms to the priorities to the white papers, conventions and best practices, policies to this meeting and this process Volunteers

5. What is needed from you… Now Show of hands for Monday’s BOF’s Camp evaluation: value, timing (length and weekends), frequency, what can make them better? Ongoing Join working groups React to developing standards Subscribe to the lists mw-announce and mw-discuss

6. Schedule

7. Monday Night BoFs Directories: Technical Implementation of Institutional Policy Middleware Project Management: A Discussion of the Organizational, Technology, and Institutional Issues Middleware Across Multi-campuses

8. 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 - Bob Morgan (UW) Chair, Scott Cantor (Ohio State), Steven Carmody (Brown), Michael Gettes (Georgetown), 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, medical issues, etc. Works via conference calls, emails, occasional serendipitous in- person meetings...

9. Internet2 Contributions Members contribute their best staff as volunteers and part-time workers Corporations contribute software, expertise, willingness to shape products, etc. Government agencies contribute services, expertise, research Internet2 staff act as layclergy.

10. National Science Foundation Catalytic grant in Fall 99 started the organized efforts, with Early Adopters and Early Adopters NSF Middleware Initiative - three year cooperative agreement, begun 9/1/01, with Internet2/EDUCAUSE/SURA and the GRIDs Center, to develop and deploy a national middleware infrastructure for science, research and higher education Work products are software, community standards, best practices, schema and objectclasses, reference implementations, open source services, corporate relations Work areas are identifiers, directories, authentication, authorization, GRIDs, PKI, video

11. What is the NMI? NSF award for integrators to Globus (NCSA, UCSD, University of Chicago, USC/ ISI, and University of Wisconsin) Internet2, EDUCAUSE, and SURA Build on the successes of the Globus project and the Internet2/MACE initiative Multi-Year Effort A practical (deployment) activity that necessitates some research and much development Separate awards to academic pure research “throw it long” components

12. The Problem NMI is Trying To Solve... To allow scientists and engineers the ability to transparently use and share distributed resources, such as computers, data, and instruments To develop effective collaboration and communications tools such as Grid technologies, desktop video, and other advanced services to expedite research and education, and To develop a working architecture and approach which can be extended to Internet users around the world. Middleware is the stuff that makes “transparently use” happen, providing consistency, security, privacy and capability

13. Desired NMI Outcomes Enable scientific and research sharing of resources Collaboration tools A model for achieving interoperability for the research and higher ed communities Influence and leverage commercial development

14. NMI activities Facilitate communication among interested parties to increase the likelihood of interoperable solutions - vendors - standards groups develop middleware tools Develop consensus around “Best Practices” Develop consensus around recommendations to support interoperability and standard directory Facilitate the development and availability of Open Source Implementations for middleware components

15. NMI Release 1 A collection of middleware materials of benefit to research and education A recipe of ingredients and integration that enable researchers to use remote resources Includes major new releases of Grid software and some new software tools extensions to community objectclasses for collaboration white papers on the middleware architectural issues in video conferencing and video on demand best practices in directories –groups –Metadirectories Available on www.nsf-middleware.org on May 7, 2002www.nsf-middleware.org

16. Release 1 Software Grid 2.0 – advanced computing and instrumentation software Condor-G – harnessing idle workstations for compute power Network Weather Service – predict host-destination performance but not end-end performance KX.509 – convert Kerberos tickets into temporary PKI certs Pubcookie – Web initial sign-on software, to provide intrarealm web single login CPM – software to help configure certificate profiles

17. NMI Release 1 Directory Items eduPerson 1.5 – an objectclass for higher ed collaboration eduOrg 1.0 – an objectclass to store higher ed institutional information comObj 1.0 – an object superclass to support desktop videoconferencing LDAP Recipe 2.0 – a guidebook on how campuses can build enterprise directories and enable applications. Best Practices in Metadirectories – technical recommendations for enterprise-wide directory services Best Practices in Groups – technical recommendations on managing groups and group math in directories

18. NMI Release 1 White Papers Video Architectural Issues in Videoconferencing Authentication and Authorization – H.323, SIP, VRVS, AG, etc. Directories and Objectclasses in Support of Videoconferencing Resource Discovery Issues and Recommendations for Videoconferencing The Role of Directories in Video on Demand PKI A Draft Certificate Policy for Higher Ed Institutions A Draft Lightweight Certificate Policy/Practice Statement for Higher Education

19. Beyond release 1 - integration The testbeds – eight institutions to test components, evaluate policies, help develop integration strategies Plumbing Campuses for Grids – Using the enterprise to leverage effective and easy use of Grids by campus researchers Underlying technical integration: security (identity, authentication and authorization) and directories architectures more than technologies recommendations and collections more than standards

20. Basics of Middleware A Few Roadmaps It begins with the enterprise Name Spaces and Authentication Directories as the key component structure and contents; inward and outward faces access to legacy data, feeding the applications metadirectories to integrate the directories The interrealm apps: Shibboleth, authn/z videoconferencing, affiliated directories, signed email and docs, etc The high-end apps: Grids, teleimmersions, etc

21. A Map of Middleware Land

22. Simple federated administration client Enterprise LDAP directory Attribute authority Authentication Service target Attribute requestor Policv decision point Policy enforcement point Policy enforcement point Policy enforcement points Video directory Service discovery service Protocols Grid directory Video directory Enterprise LDAP directory

23. Middleware Inputs & Outputs Grids JA-SIG & uPortalOKIInter-realmcalendaring Shibboleth, eduPerson, Affiliated Dirs, etc. EnterpriseDirectoryEnterpriseAuthenticationLegacySystemsCampus web SSO futures EnterpriseauthZ LicensedResourcesEmbedded App Security Shibboleth, eduPerson, and everything else

24. Enterprise Name Spaces and Authentication Identifiers and their policies How and where to crosswalk identifiers Authentication the initial I/A enterprise versus local processes strong and weak technologies strong and weak practices Separating authn and authz

25. Identifiers “Any problem in Computer Science can be solved with another level of indirection” Butler Lampson “Except the problem of indirection complexity” Bob Morgan

26. Major campus identifiers UUID Student and/or emplid Person registry ID Account login ID Enterprise-LAN ID Student ID card Net ID Email address Library/departmental ID Publicly visible ID (and pseudo- SSN) Pseudonymous ID

27. General Identifier Characteristics Uniqueness (within a given context) Dumb vs intelligent (i.e. whether subfields have meaning) Readability (machine vs human vs device) Affordance (centrally versus locally provided) Resolver approach (how identifier is mapped to its associated object) Metadata (both associated with the assignment and resolution of an identifier) Persistence (permanence of relationship between identifier and specific object) Granularity (degree to which an identifier denotes a collection or component) Format (checkdigits) Versions (can the defining characteristics of an identifier change over time) Capacity (size limitations imposed on the domain or object range) Extensibility (the capability to intelligently extend one identifier to be the basis for another identifier).

28. Important Characteristics/Policies Semantics and syntax- what it names and how does it name it Domain - who issues and over what space is identifier unique Revocation - can the subject ever be given a different value for the identifier Reassignment - can the identifier ever be given to another subject Opacity - is the real world subject easily deduced from the identifier - privacy and use issues

29. Identifier Mapping Process Map campus identifiers against a canonical set of functional needs For each identifier, establish its key characteristics, including revocation, reassignment, privileges, and opacity Shine a light on some of the shadowy underpinnings of middleware A key first step towards the loftier middleware goals

30. Authentication Options Password based Clear text LDAP Kerberos (Microsoft or K5 flavors) Certificate based Others - challenge-response, biometrics Inter-realm is now the interesting frontier Web initial sign-on key tool: connects web services to account login

31. Some authentication good practices Precrack new passwords Precrack using foreign dictionaries as well as US Confirm new passwords are different than old Require password change if possibly compromised Use shared secrets or positive photo ID to reset forgotten passwords US Mail a one-time password (time-bomb) In-person with a photo ID (some require two) For remote faculty or staff, an authorized departmental representative in person, coupled with a faxed photo ID Initial identification/authentication will emerge as a critical component of PKI

32. Directories Applications Overall architecture chaining and referrals, redundancy and load balancing, replication, synchronization, directory discovery The Schema and the DIT attributes, ou’s, naming, object classes, groups Attributes and indexing Management clients, delegation of access control, data feeds

33. Directory-enabled applications Email Account management Web access controls Portal support Calendaring Grids

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

35. Shibboleth An architecture, and corresponding reference open-source implementations, for interrealm exchange of authorization and authentication information. Oriented towards privacy, and enables networked identity and privacy with accountability Addresses many higher ed problems, including off-campus access to library holdings, portal management, integration of learning management systems, sharing of web sites, etc. May be leveraged into videoconferencing, digital rights management, etc. In alpha-2 stage now, beta in August, release of 1.0 in Oct

36. Inter and intra-realm Campus authentication Enterprise directory Web services and servers WebISO Learning Management Systems Personal Portals Objectclass standards (e.g.eduperson, gridperson) Content Portals Shibboleth exchange of attributes Future PKI DODHE et al Future PKI Interrealm Security Domain Grids et al

37. What is the nature of the campus work? Technological Establish campus-wide services: name space, authentication Build an enterprise directory service Populate the directory from source systems Enable applications to use the directory Policies and Politics Clarify relationships between individuals and institution Determine who manages, who can update and who can see common data Structure information access and use rules between departments and central administrative units Reconcile business rules and practices

38. What are the benefits to the institution? Economies for central IT - reduced account management, better web site access controls, tighter network security... Economies for distributed IT - reduced administration, access to better information feeds, easier integration of departmental applications into campus-wide use... Improved services for students and faculty - access to scholarly information, control of personal data, reduced legal exposures... Participation in future research environments - Grids, videoconferencing, etc. Participation in new collaborative initiatives - DoD, Shibboleth, etc.

39. What are the costs to the institution? Modest increases in capital equipment and staffing requirements for central IT Considerable time and effort to conduct campus wide planning and vetting processes One-time costs to retrofit some applications to new central infrastructure One-time costs to build feeds from legacy source systems to central directory services The political wounds from the reduction of duchies in data and policies

40. Consult thy neighbor Where are you with enterprise name spaces? What is the extent and approach to a central authentication service? What is in your enterprise directory? What applications use the directory?