Middleware CAMP June 2002

1. Middleware CAMPJune 2002

2. Welcome • Welcome to the Camp, I guess you all know why we're here.Tommy, byPete Townsend, The Who • We're not gonna take itNever did and never willWe're not gonna take itGonna break it, gonna shake it,let's forget it better still

3. Orientation 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. 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 What is needed from you…

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. 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 The Problem NMI is Trying To Solve...

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, 2002

16. 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 Release 1 Software

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 Service discovery service Policy enforcement point Policy enforcement point Policy enforcement points Authentication Service client target Protocols Enterprise LDAP directory Attribute authority Enterprise LDAP directory Attribute requestor Policv decision point Grid directory Video directory Video directory

23. Shibboleth, eduPerson, and everything else 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

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. 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 Major campus identifiers

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 border directory metadirectory Enterprise applications dir enterprise directory departmental directories OS directories (MS, Novell, etc) directory database registries source systems

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 Objectclass standards (e.g.eduperson, gridperson) Content Portals Shibboleth exchange of attributes Future PKI DODHE et al Grids et al Interrealm Learning Management Systems Security Domain Personal Portals Web services and servers WebISO Enterprise directory Campus authentication Future PKI

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?