1 / 81

Middleware Tutorial and Use

Middleware Tutorial and Use. Renee Woodten Frost Project Manager, Internet2 Middleware Initiative Internet2 Middleware Liaison, University of Michigan ARKNet 2001 28 March 2001. Topics. Acknowledgements The larger picture Core middleware: the basic technologies Identifiers

brownarthur
Download Presentation

Middleware Tutorial and Use

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Middleware Tutorial and Use Renee Woodten Frost Project Manager, Internet2 Middleware Initiative Internet2 Middleware Liaison, University of Michigan ARKNet 2001 28 March 2001

  2. Topics • Acknowledgements • The larger picture • Core middleware: the basic technologies • Identifiers • Authentication • Directories • Authorization • PKI • The major projects • EduPerson, LDAP Recipe, the Directory of Directories, Shibboleth, HEPKI • What to do and where to watch? ARKNet 2001

  3. 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... Government partners - including NSF and the fPKI TWG Acknowledgements ARKNet 2001

  4. 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 (U California), Von Welch (Grid) • Creates working groups in major areas, including directories, inter-realm authentication, PKI, medical issues, video, etc. • Works via conference calls, emails, occasional serendipitous in-person meetings... ARKNet 2001

  5. 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/ ARKNet 2001

  6. 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. ARKNet 2001

  7. Dartmouth Univ of Hawaii Johns Hopkins Univ Univ of Maryland, Baltimore County Univ of Memphis Univ of Michigan Michigan Tech Univ Univ of Pittsburgh Univ of Southern California Tufts Univ Univ of Tennessee Health Science Center, Memphis Early Adopter Participants ARKNet 2001

  8. Partnerships • EDUCAUSE • CREN • Grids, JA-SIG, OKI • Campuses • Higher Ed professional associations - AACRAO, NACUA, CUMREC, etc. • Increasing international interactions • Corporate - IBM, SUN, ATT, etc. ARKNet 2001

  9. 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 Remedial IT architecture ARKNet 2001

  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 ARKNet 2001

  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. relies on campus-based services and inter-institutional standards • Instructional Management Systems (IMS) needs 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 ARKNet 2001

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

  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. ARKNet 2001

  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 ARKNet 2001

  15. What is the nature of the 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 ARKNet 2001

  16. 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. ARKNet 2001

  17. 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 ARKNet 2001

  18. OIDs to reference identifiers • Numeric coding to uniquely define many middleware elements, such as directory attributes and certificate policies. • Numbering is only for identification (are two oids equal? If so, the associated objects are the same); no ordering, search, hierarchy, etc. • Distributed management; each campus typically obtains an “arc”, e.g. 1.3.4.1.16.602.1, and then creates oids by extending the arc, e.g 1.3.4.1.16.602.1.0, 1.3.4.1.16.602.1.1, 1.3.4.1.16.602.1.1.1 • More info at: http://middleware.internet2.edu/a-brief-guide-to-OIDs.doc ARKNet 2001

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

  20. 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). ARKNet 2001

  21. 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 ARKNet 2001

  22. 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 ARKNet 2001

  23. 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 ARKNet 2001

  24. Cuttings: Authentication • User side management - crack, change, compromise • Central side password management - change management, OS security • First password assignment - secure delivery • Policies - restrictions or requirements on use ARKNet 2001

  25. Some Authentication Good Practices • Pre-crack new passwords • Pre-crack 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 ARKNet 2001

  26. Directory Issues • Applications • Overall architecture • Chaining and referrals, Redundancy and Load Balancing, Replication, synchronization, Directory discovery • The Schema and the Directory Information Tree (DIT) • attributes, ou’s, naming, object classes, groups • Attributes and indexing • Management • clients, delegation of access control, data feeds ARKNet 2001

  27. Directory-enabled Applications • Email • Account management • Web access controls • Portal support • Calendaring • Grids ARKNet 2001

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

  29. 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/ Key Architectural Issues ARKNet 2001

  30. 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 ARKNet 2001

  31. Attribute Good Practices • INetOrgPerson, eduPerson, localPerson • Never repurpose an RFC defined field; add new attributes • Adding attributes is easier than thought • Keep schema checking on, unless it is done in the underlying database; watch performance • Most LDAP clients do not treat multi-valued attributes well, but doing multiple fields and separate dn’s no better. ARKNet 2001

  32. Management Good Practices • No trolling permitted; more search than read • LDAP client access versus web access • Give deep thought to who can update • Give deep thought to when to update • LDIF likely to be replaced by XML as exchange format • Delegation of control - scalability • “See also”, referrals, replication, synchronization in practice • Replication should not be done tree-based but should be filtered by rules and attributes ARKNet 2001

  33. 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) ARKNet 2001

  34. 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. • 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. ARKNet 2001

  35. 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... ARKNet 2001

  36. PKI Components • X.509 v3 certificates - profiles and uses • Validation - Certificate Revocation Lists, OCSP, path construction • Certificate 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 ARKNet 2001

  37. PKI Contexts for Usage • Intracampus • Within the Higher Ed community of interest • In the Broader World ARKNet 2001

  38. PKI Implementation Options • In-source - with public domain or campus unique • In-source - with commercial product • Bring-in-source - with commercial services • Out-source - a spectrum of services and issues • what you do depends on when you do it... ARKNet 2001

  39. What Isn’t Here Yet… • Certificate Policies and Practice Statements • Inter-realm trust structures • Mobility ARKNet 2001

  40. The Gathering Cloudsaka Tightly-Knit Vapor • PKI - the research labs and HEPKI-TAG, PAG • eduPerson • the Directory of Directories • Shibboleth • Medical Middleware ARKNet 2001

  41. 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 ARKNet 2001

  42. HEPKI (www.educause.edu/hepki) • HEPKI - Technical Activities Group (TAG) • universities actively working technical issues • topics include Kerberos-PKI integration, public domain CA, profiles • regular conf calls, email archives • HEPKI - Policy Activities Group (PAG) • universities actively trying to deploy PKI • topics include certificate policies, RFP sharing, interactions with state governments • regular conf calls, email archives ARKNet 2001

  43. Activities • Mace - RL “Bob” Morgan (Washington) • Early Harvest / Early Adopters -Renee Frost (Michigan) • LDAP Recipe - Michael Gettes (Georgetown) • EduPerson - Keith Hazelton (Wisconsin) • Directory of Directories - Michael Gettes (Georgetown) • Metadirectories - Keith Hazelton (Wisconsin) • Shibboleth - Steven Carmody (Brown) • PKI Labs - Dartmouth and Wisconsin • HEPKI-TAG and PAG - Jim Jokl (Virginia) and Ken Klingenstein (Colorado) • HEBCA - Mark Luker (EDUCAUSE) • Medical Middleware - Rob Carter (Duke) • Opportunities - video, the GRID, K-12 ARKNet 2001

  44. Early Harvest and Early Adopters • Early harvest in the barn… • http://middleware.internet2.edu/best-practices.html • Early adopters aggressively doing deployments • http://middleware.internet2.edu/earlyadopters • MTU, UMBC, JHU • http://www.colorado.edu/committees/DirectoryServices/ ARKNet 2001

  45. 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/ ARKNet 2001

  46. 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. Presumes campuses to add local person objectclass. A joint effort of EDUCAUSE and I2 eduPerson ARKNet 2001

  47. 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.) Issues about Upper Class Attributes ARKNet 2001

  48. eduPersonAffiliation multi-valued list of relationships an individual has with institution controlled vocabulary includes:faculty, staff, student, alum, member, affiliate,employee applications that use: DoD, white pages eduPersonPrinicipleName userid@securitydomain EPPN may look like an email address but it is used by different systems One must be able to authenticate against the EPPN Used in inter-realm authentication such as Shibboleth In some situations it can be used for access control lists; if used, a site should make sure what the reassignment policy is. Examples of eduPerson Attributes ARKNet 2001

  49. eduPerson 1.0 done, along with FAQ and letter to implementers Ties closely to LDAP recipe Version 2.0 to include attributes for videoconferencing, additional collaboration factors, links to Grids, portals, etc. Check with web site for additional changes Participate: mace-dir@internet2.edu Next Steps ARKNet 2001

  50. 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 ARKNet 2001

More Related