1. Middleware: High Technical Bandwidth, High Political Latency Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder

2. Topics Acknowledgments What is Middleware Core middleware: the basic technologies Identifiers Authentication Directories PKI The Gathering Clouds (aka Tightly-Knit Vapor) Eduperson, the Directory of Directories, Shibboleth, HEPKI What to do and where to watch?

3. Other middleware sessions Mware 101 - big picture, identifier basics, authn, directory concepts, PKI overview Mware 202 - identifiers+, directory deployments PKI 101 - apps, certs, profiles, policies, trust models HEPKI- PAG - current policy activities Middleware 301 - metadirectories, registries, authorization Early Adopters technology --- policy LDAP Recipe HEPKI- TAG - current technical activities Multicampus BoF Academic Medical Middleware International Issues in Middleware Labs: Eduperson Shibboleth DoD, apps Middleware and the Grid Metadirectories BoF

4. Acknowledgements Mace and the working groups Early Harvest - NSF catalytic grant and meeting Early Adopters Higher Ed partners -campuses, EDUCAUSE, CREN, AACRAO, NACUA, etc Corporate partners - IBM, ATT, SUN, et al... Gov’t partners - including NSF and the fPKI TWG

5. 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), Jim Jokl (Virginia), Mark Poepping (CMU), David Wasley (California), Von Welch (Grid) Creates working groups in major areas, including directories, interrealm authentication, PKI, medical issues, etc. Works via conference calls, emails, occasional serendipitous in- person meetings...

6. Early Harvest NSF funded workshop in Fall 99 and subsequent activities Defined the territory and established a work plan Best practices in identifiers, authentication, and directories (http://middleware.internet2.edu/best-practices.html) http://middleware.internet2.edu/earlyharvest/

7. 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 Profiles and plans are on I2 middleware site.

8. Early Adopter Participants 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

9. Remedial IT architecture The proliferation of customizable applications requires a centralization of “customizations” The increase in power and complexity of the network requires access to user profiles Electronic personal security services is now an impediment to the next-generation computing grids Inter-institutional applications require interoperational deployments of institutional directories and authentication

10. What is Middleware? specialized networked services that are shared by applications and users a set of core software components that permit scaling of applications and networks tools that take the complexity out of application integration sits above the network as the second layer of the IT infrastructure a land where technology meets policy the intersection of what networks designers and applications developers each do not want to do

11. Specifically, 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. This relies on campus-based services and inter-institutional standards Instructional Management Systems (IMS) need authentication and directories Next-generation portals want common authentication and storage Academic collaboration requires restricted sharing of materials between institutions What I1 did with communication, I2 may do with collaboration

12. A Map of Middlewareland Network-layer middleware Core middleware Academic Computing Upperware Research Oriented Upperware Business Upperware

13. The Grid a model for a distributed computing environment, addressing diverse computational resources, distributed databases, network bandwidth, object brokering, security, etc. Globus (www.globus.org) is the software that implements most of these components; Legion is another such software environment Needs to integrate with campus infrastructure Gridforum (www.gridforum.org) umbrella activity of agencies and academics Look for grids to occur locally and nationally, in physics, earthquake engineering, etc.

14. Core Middleware Identity - unique markers of who you (person, machine, service, group) are Authentication - how you prove or establish that you are that identity Directories - where an identity’s basic characteristics are kept Authorization - what an identity is permitted to do PKI - emerging tools for security services

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

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

17. 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).

18. Important Characteristics 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

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

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

21. 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 USmail a one-time password (time-bomb) In-person with a photo id (some require two) For remote faculty or staff,, an authorized departmental rep in person coupled with a faxed photo-id. Initial identification/authentication will emerge as a critical component of PKI

22. Directory Issues Applications Overall architecture Chaining and referrals, Redundancy and Load Balancing, Replication, synchronization, Directory discovery The Schema and the DIT attributes, ou’s, naming, objectclasses, groups Attributes and indexing Management clients, delegation of access control, data feeds

23. Directory-enabled applications Email Account management Web access controls Portal support Calendaring Grids QoS and maybe secure multicast

24. A Campus Directory Architecture Metadirectory Enterprise directory Dir DB Departmental directories OS directories (MS, Novell, etc) Border directory Registries Source systems

25. Key Architectural Issues Interfaces and relationships with legacy systems Performance in searching Binding to the directory Load balancing and backups are emerging but proprietary Who can read or update what fields How much to couple the enterprise directory with an operating system http://www.georgetown.edu/giia/internet2/ldap-recipe/

26. Schema and DIT Good Practices People, machines, services Be very flat in people space Keep accounts as attributes, not as an ou Replication and group policies should not drive schema RDN name choices rich and critical Other keys to index Creating and preserving unified name spaces

27. PKI First thoughts Fundamentals - Components and Contexts The missing pieces - in the technology and in the community Higher Ed Activities (CREN, HEPKI-TAG, HEPKI-PAG, Net@edu, PKI Labs)

28. PKI: A few observations Think of it as wall jack connectivity, except it’s connectivity for individuals, not for machines, and there’s no wall or jack…But it is that ubiquitous and important Does it need to be a single infrastructure? What are the costs of multiple solutions? Subnets and ITPs... Options breed complexity; managing complexity is essential PKI can do so much that right now, it does very little.

29. A few more... IP connectivity was a field of dreams. We built it and then the applications came. Unfortunately, here the applications have arrived before the infrastructure, making its development much harder. No one seems to be working on the solutions for the agora.

30. Uses for PKI and Certificates authentication and pseudo-authentication signing docs encrypting docs and mail non-repudiation secure channels across a network authorization and attributes secure multicast and more...

31. PKI Components X.509 v3 certs - profiles and uses Validation - Certificate Revocation Lists, OCSP, path construction Cert management - generating certs, using keys, archiving and escrow, mobility, etc. Directories - to store certs, and public keys and maybe private keys Trust models and I/A Cert-enabled apps

32. PKI Contexts for Usage Intracampus Within the Higher Ed community of interest In the Broader World

33. X.509 certs purpose - bind a public key to a subject standard fields extended fields profiles to capture prototypes client and server issues v2 for those who started too early, v3 for current work, v4 being finalized to address some additional cert formats (attributes, etc.)

34. Standard fields in certs cert serial number the subject, as x.500 DN or … the subject’s public key the validity field the issuer, as id and common name signing algorithm signature info for the cert, in the issuer’s private key

35. Extension fields Examples - auth/subject subcodes, key usage, LDAP URL, CRL distribution points, etc. Key usage is very important - for digsig, non-rep, key or data encipherment, etc. Certain extensions can be marked critical - if an app can’t understand it, then don’t use the cert Requires profiles to document, and great care...

36. Cert Management Certificate Management Protocol - for the creation, revocation and management of certs Revocation Options - CRL, OCSP Storage - where (device, directory, private cache, etc.) and how - format (DER,BER, etc.) Escrow and archive of keys - when, how, and what else needs to be kept Cert Authority Software or outsource options Homebrews Open Source - OpenSSL, OpenCA, Oscar Third party - Baltimore, Entrust, etc. OS-integrated - W2K, Sun/Netscape, etc.

37. Directories to store certs to store CRL to store private keys, for the time being to store attributes implement with border directories, or ACLs within the enterprise directory, or proprietary directories

38. What Isn’t Here Yet… Scalable revocation Standard certificate profiles Certificate Policies and Practice Statements Interrealm trust structures Mobility

39. The Gathering Clouds aka Tightly-Knit Vapor PKI - the research labs and HEPKI-TAG, PAG Eduperson and the LDAP Recipe the Directory of Directories Shibboleth

40. Internet2 PKI Labs At Dartmouth and Wisconsin in computer science departments and IT organizations Doing the deep research - two to five years out Policy languages, path construction, attribute certificates, etc. National Advisory Board of leading academic and corporate PKI experts provides direction Catalyzed by startup funding from ATT

41. HEPKI-TAG chaired by Jim Jokl, Virginia certificate profiles survey of existing uses development of standard presentation identity cert standard recommendation mobility options - SACRED scenarios public domain software alternatives

42. HEPKI-PAG David Wasley, prime mover draft certificate policy for a campus HEBCA certificate policy FERPA State Legislatures Gartner Decision Maker software

43. eduPerson a directory objectclass intended to support inter-institutional applications fills gaps in traditional directory schema for existing attributes, states good practices where known specifies several new attributes and controlled vocabulary to use as values. provides suggestions on how to assign values, but it is up to the institution to choose. Version 1.0 almost done; one or two revisions anticipated

44. Issues about Upper Class Attributes eduperson inherits attributes from person, inetorgperson Some of those attributes need conventions about controlled vocabulary (e.g. telephones) Some of those attributes need ambiguity resolved via a consistent interpretation (e.g. email address) Some of the attributes need standards around indexing and search (e.g. compound surnames) Many of those attributes need access control and privacy decisions (e.g jpeg photo, email address, etc.)

45. New eduPerson Attributes edupersonAffiliation edupersonPrimaryAffiliation edupersonOrgDN edupersonOrgUnitDN edupersonPrincipalName edupersonNickname edupersonSchoolCollegeName ***

46. LDAP Recipe how to build and operate a directory in higher ed 1 Tsp. DIT planning 1 Tbsp Schema design 3 oz. configuration 1000 lbs of data good details, such as tradeoffs/recommendations on indexing, how and when to replicate, etc. http://www.georgetown.edu/giia/internet2/ldap-recipe/

47. A Directory of Directories an experiment to build a combined directory search service to show the power of coordination will highlight the inconsistencies between institutions technical investigation of load and scaling issues, centralized and decentralized approaches human interfaces issues - searching large name spaces with limits by substring, location, affiliation, etc... Two different experimental regimes to be tested centralized indexing and repository with referrals large-scale parallel searches with heuristics to constrain search space SUN donation of server and iPlanet license (6,000,000 dn’s) Michael Gettes, Georgetown project manager

48. DoD Architecure Inputs to DoDHE Inputs: Local Site View Central Deposit Service DoDConfig Directory Operation Search Operations Search Drill Down from a list

49. Inputs Remote Site Directories Remote Data Sources Central Deposit Systems (CDS) Data Filtering & Submit to CDS LDAP Oracle Etc… Search DoD Config

50. Inputs: Local Site View Local Data Source CDS LDAP Generate LDIF Data Submit final LDIF to CDS using authenticated POST via HTTPS. Filter LDIF according to local policy. Generate new LDIF for submission. DODHEDODHE

51. Operation User search request Search DoDConfig for Orgs to Scan in dc=edu tree (with do not follow referrals ctl set). Collect dodBase attributes. Search all directories (remote or CDS, as specified by dodBase) List results Drill down (view full entry) follows referral back to home directory by using DN of object in question or uses Chaining ability of iPlanet DS 5 Display object.

52. Search Operations SearchBase = “dc=edu” Filter = (OrgCriteria from Search page) Remote Site Directories CDS Search DoD Config Search Search using SearchBases From DoDConfig Results o=University,c=US dc=domain,dc=edu No Referrals Referrals?

53. Drill Down from List Remote Site Directories CDS DoD Config Follows referral from Ref: attribute (smart-referral) in DoDConfig Directory or use chaining ability of iPlanet DS 5. Results o=University,c=US dc=domain,dc=edu Follow Referrals Referrals? Obtains object by DN in home Directory Display found object in web page From a list of results of a search … A list of results from a search … Obtain object

54. Metadirectories: Architech www.architech.no Higher Education Contact for USA Keith Hazelton, University of Wisconsin – Madison hazelton@doit.wisc.edu This product is available free of charge to Higher Ed in USA Source code will be in escrow. See Keith for further details.

55. Architech: Main View

56. Shibboleth A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce sh, called the word sibboleth. See --Judges xii. Hence, the criterion, test, or watchword of a party; a party cry or pet phrase. - Webster's Revised Unabridged Dictionary (1913):Webster's Revised Unabridged Dictionary (1913)

57. Shibboleth interinstitutional web authentication and basic authorization authenticate locally, act globally - the Shibboleth shibboleth emphasizes privacy through progressive disclosure of attributes linked to commercial standards development in XML through OASIS scenarios done; architecture next; implementation by fall strong partnership with IBM to develop and deploy

58. Isn’t This What PKI Does? PKI does this and a whole lot more; as a consequence, PKI does very little right now End-to-end PKI fits the Shibboleth model, but other forms of authentication do as well Uses a lightweight certificate approach for inter-institutional communications - uses the parts of PKI that work today (server side certs) and avoids the parts of PKI that don’t work today (eg client certs). Allows campuses to use other forms of authentication locally May actually have benefits over the end-user to target-site direct interactions...

59. Assumptions Leverage vendor and standards activity wherever possible Disturb as little of the existing campus infrastructure as possible Encourage good campus behaviors Learn through doing Create a marketplace and reference implementations We will not be another dead guppy

60. Stage 1 - Addressing Three Scenario’s Member of campus community accessing licensed resource Anonymity required Member of a course accessing remotely controlled resource Anonymity required Member of a workgroup accessing controlled resources Controlled by attributes, perhaps including identity

61. Campus and Resource Requirements campus-wide identifier space campus-wide authentication service Implementation of Eduperson objectclass

62. Issues Personal Privacy (reasonable expectation, laws) Relation to local weblogin (Single Signon) Portals Use of Shibboleth framework by services beyond the web Grid resources and users

63. Project Status/Next Steps Requirements and Scenarios document nearly finished IBM and Mace-Shibboleth are refining architecture and evaluating issues IBM intends to develop an Apache web module Internet2 intends to develop supporting materials (documentation, installation, etc) and web tools (for htaccess construction, filter and access control, remote resource attribute discovery). Technical design complete - April, 2001 Coding... Pilot site start-up - Aug, 2001 Public demo- Internet2 Fall Member Meeting 2001

64. More information Early Harvest / Early Adopters - http://middleware.internet2.edu/earlyadopters/ Mace - middleware.internet2.edu LDAP Recipe - http://www.georgetown.edu/giia/internet2/ldap- recipe/ Eduperson - www.educause.edu/eduperson Directory of Directories - middleware.internet2.edu/dodhe Shibboleth - middleware.internet2.edu/shibboleth HEPKI-TAG - www.educause.edu/hepki HEPKI-PAG - www.educause.edu/hepki Medical Middleware - web site to follow Opportunities - video, the GRID, K-12