Current Activities in Middleware

1. Current Activities in Middleware Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder

2. Application requirements - Digital libraries, Grids, IMS, Portals, etc... Early Harvest best practices Early Adopters Mace (Middleware Architectural Committee for Education) Experiments: Shibboleth, the Directory of Directories, and Eduperson PKI Medical middleware International Efforts Topics

3. Application Requirements • Digital libraries need scalable, interoperable authentication and authorization. • The Grid as the new paradigm for a computational resource, with Globus the middleware, including security, location and allocation of resources, scheduling, etc. built on top of campus infrastructures. • Instructional Management Systems (IMS) need authentication and directories • Next-generation portals want common authentication and storage

4. Partnerships • EDUCAUSE • CREN • Globus, Legion, etc. • Campuses • Professional associations - AACRAO, NACUA, CUMREC

5. Identifiers for people, objects, groups Authentication for people, objects and groups Directories to store common information Authorization services Applications that use all of the above Complex design and implementation tradeoffs at technical and policy levels The Early Harvest experiences

6. Identifier mapping Good practice documents on middleware web site, to guide campus IT organizations Informational RFC in June May form part of the basis for an assurance model for higher ed PKI Early Harvest Outputs

7. Identifier Mapping • 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

8. UUID Student and/or emplid Person registry id Account login id Enterprise-lan id Netid Email address Library/deptl id Publicly visible id (and pseudossn) Pseudonymous id Major campus identifiers

9. Identifier Characteristics • Revocation - can the subject ever be given a different value for the identifier • Reassignment - can the identifier ever be given to another subject • Privileges - what accesses does the authenticated identifier have • Opacity - is the real world subject easily deduced from the identifier - privacy and use issues

10. Identifier relationships Library ID PubVis ID Enterprise-LAN ID ISO card ID Student ID Email address UUID Empl ID Pseudo ID Acct login Departmental IDs Person registry ID

11. Authentication Options • Password based • Clear text • LDAP • Kerberos • Certificate based • Others - challenge-response, biometrics

12. Typical Good Practices • Have a UUID that is non-revocable, non-reassignable, opaque • No clear text passwords • Precrack new passwords, 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 • Password strength depends on use...

13. Typical Interoperability Standards • dc= instead of X.500 for naming of directory suffixes, certificate subjects, etc. • use of certain object class • future standardization of certificate profiles

14. Directories: Core of the Core • Overall campus directory services model • Enterprise directory design and implementation • Departmental directories • Security and directories

15. Enterprise directory issues • Schema, referrals and redundancy • Naming • Attributes • Replication and synchronization • Groups

16. Early Adopters: The Campus Testbed Phase • A variety of roles and missions • Commitment to move implementation forward • Provided some training and facilitated support • Develop national models of deployment alternatives • Address policy standards

17. Dartmouth U Hawaii Johns Hopkins Univ of Maryland, BC Univ of Memphis Univ of Michigan Michigan Tech Univ Univ of Pittsburgh Univ of Southern Cal Tufts Univ Univ of Tennessee, Memphis Early Adopter Participants

18. Primary Goals • to facilitate the campus deployments of core middleware technologies • to identify reasonable approaches - both technical and policy - and design issues and factors that influence institutional selection of a particular approach • to enrich the technical contents of Early Harvest • to inform larger community (NSF, Education, NIH, etc) of requirements for deployment and interoperability

19. Secondary Goals • explore medical middleware issues • Generic - how is this expressed in the core deployment • Specific - what medical data structures need integration into campus environment • outreach to encourage other institutions • research into options for authorization services • evaluate new tools and technologies

20. Basic Approaches • technology sharing and workshops • policy sharing • champions • data owners • professional associations - EDUCAUSE, CNI, NACUA, NACUBO, AACRAO, ALA, • external experts • vendor interactions

21. MACE (Middleware Architecture Committee for Education) • Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher ed • Membership - Bob Morgan (UW) Chair, Steven Carmody (Brown), Michael Gettes (Georgetown), Keith Hazelton (Wisconsin), Paul Hill (MIT), Mark Mara (Cornell), Mark Poepping (CMU) • Current working Groups • DIR - eduperson, the Uber-directory experiment • PKI - campus operational issues, trust models, fPKI involvement • Shibboleth - inter-institutional resource sharing

22. A Directory of Directories • an experiment, now encompassing 8 schools, to build a combined directory search service • to show the power of coordination • to show the existing barriers to cooperation • standard object classes • standard display formats • standard meta-data • to investigate load and scaling issues - on the clients and the servers • to suggest the service to follow

23. Edu-person • An objectclass for higher education • Contain suggested attributes for instructional, research and administrative inter-institutional use • Presumes campuses to add local person objectclass. • A joint effort of EDUCAUSE and I2

24. edu-person 0.9a • parent objectclass=inetorgperson • intends to integrate with Grid, IMS, and other upper-middleware • includes: • primary affiliation (fac/stu/staff) • enrolledcurrentterm (binary true/false) • withdrawnpreviousterm (binary) • schoolcollegename, (multivalued case ignore strings)

25. Shibboleth • interinstitutional web authentication and perhaps authorization • use local credentials for remote services; enable user@ logins; fosters best practices; encourage transition from simple ht controls to LDAP-based • uses SRV records in DNS and several forms of authn; authz via directories • IBM to analyze, several schools to participate in pilot

26. Medical middleware • the intersection of higher ed and health care services • worst case requirements in I/A • HIPAA - new privacy and security requirements • must integrate with higher level objects - CORBA Med • work will consist of problem structuring, technologies, and policy/process issues

27. International Aspects • identifier agreements • international trust models • shared expertise • workshop this summer in Europe

28. Authorization • how an individual’s attributes are carried from an individual or a central store to an application • move from a per-application basis to an infrastructural service • options include • Kerberos tickets • LDAP calls • RPC’s • long-term certificates • attribute certificates

29. PKI • Public Key Certificates are a remarkably simple and powerful tool for • signing documents authentication encrypting email building secure channels across the Internet • non-repudiation conveying authorizations and more • Infrastructure to support this little understood • mobility user interface internal formats • trust chains revocation policy expression • See Current Issues in PKI on middleware.internet2.edu for details

30. Where to watch • www.internet2.edu/middleware • net@edu • cren.org • fPKI work • Globus.org