1 / 81

Middleware 101

Middleware 101. Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder. Syllabus. Process and acknowledgments The larger picture Core middleware: the basic technologies Identifiers Authentication Directories PKI

Albert_Lan
Télécharger la présentation

Middleware 101

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 101 Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder

  2. Syllabus • Process and acknowledgments • The larger picture • Core middleware: the basic technologies • Identifiers • Authentication • Directories • PKI • The major projects • eduPerson, LDAP Recipe, the Directory of Directories, Shibboleth, HEBCA, HEPKI • What lies ahead • What to do and where to watch

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

  4. MACE and the working groups NSF catalytic grant and meeting Early Adopters Higher Education partners - campuses, EDUCAUSE, CREN, AACRAO, SURA, NACUA, etc. Corporate partners - IBM, ATT, Sun, Accord, Metamerge, et al. Government partners - including NSF and the fPKI TWG Acknowledgments

  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 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) • 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. National Science Foundation • Catalytic grant in Fall 99 started the organized efforts, with Early Harvest 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 community standards, best practices, schema and object classes, reference implementations, open source services, corporate relations • Work areas are identifiers, directories, authentication, authorization, GRIDs, PKI, video

  7. 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/internet2-mi-best-practices-00.html) • http://middleware.internet2.edu/earlyharvest/

  8. 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 Internet2 middleware site

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

  10. Partnerships • EDUCAUSE • CREN, CNI • Grids, JA-SIG, OKI • campuses • higher education professional associations - AACRAO, NACUA, CUMREC, etc. • increasing international interactions • corporate - IBM, Sun, ATT, etc.

  11. 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 are now an impediment to the next-generation computing grids Inter-institutional applications require interoperational deployments of institutional directories and authentication Remedial IT architecture

  12. 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 • a second layer of the IT infrastructure, sitting above the network • a land where technology meets policy • the intersection of what networks designers and applications developers each do not want to do

  13. Specifically… • Digital libraries need scalable, interoperable authentication and authorization. • The Grid is a new paradigm for a computational resource; Globus provides middleware, including security, location and allocation of resources, and scheduling. This relies on campus-based services and inter-institutional standards. • Instructional Management Systems need authentication and directories. • Next-generation portals want common authentication and storage. • Academic collaboration requires restricted sharing of materials between institutions. • Last time it was about communication; this time it’s about collaboration.

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

  15. A Map of Middleware

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

  17. Identity Services on One Slide 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

  18. Simple point-to-point model Service discovery service Policy enforcement point Policy enforcement point Policy enforcement points Authentication Service client target Protocols Enterprise LDAP directory Enterprise LDAP directory Attribute requestor Policv decision point Attribute authority Grid directory Video directory Video directory

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

  20. 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 - DoDHE, Shibboleth, etc.

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

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

  23. Getting an OID • apply at IANA at http://www.iana.org/cgi-bin/enterprise.pl • apply at ANSI at http://web.ansi.org/public/services/reg_org.html • more info at http://middleware.internet2.edu/a-brief-guide-to-OIDs.doc

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

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

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

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

  28. 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 toward the loftier middleware goals

  29. 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 needs to relate to account login

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

  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. 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, 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. 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/ Which attributes and object classes in which directories Key Architectural Issues

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

  37. 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 is no better.

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

  39. Metadirectories • The critical functions to glue together what inevitably turns out to be a number of campus, departmental and application-oriented directory services • Typically a coordinated set of services that watches updates to specific directories or from legacy data feeds and spreads those updates to other directories • Performs several subfunctions • an identity registry or crosswalk to relate entries in different directories • a set of connectors that take changes from one source and convert them for dissemination to other sources • Basic implementation from Metamerge is free to higher ed

  40. PKI • First thoughts • Fundamentals - Components and Contexts • The missing pieces - in the technology and in the community • Higher Education activities (CREN, HEPKI-TAG, HEPKI-PAG, Net@EDU, PKI Labs)

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

  42. 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. • A general-purpose PKI seems like a difficult task, but instituting a PKI Light as a first step may not have enough paybacks.

  43. The general state of PKI • There are campus and corporate successes • Corporations use internally for VPN, some authentication, signed email (with homogeneous client base) • MIT, UT medical, soon VA, UCOP • Key is limited application use, lightweight policy approaches • There is very limited interrealm, community of interest or general interoperable work going on • Federal efforts • HealthKey • Higher Ed • Some European niches

  44. Single infrastructure to provide all security services Established technology standards, though little operational experience Elegant technical underpinnings Serves dozens of purposes - authentication, authorization, object encryption, digital signatures, communications channel encryption Low cost in mass numbers Why X.509/PKI?

  45. High legal barriers Lack of mobility support Challenging user interfaces, especially with regard to privacy and scaling Persistent technical incompatibilities Overall complexity Why Not X.509/PKI?

  46. on the road to general purpose interrealm PKI the planes represent different levels of simplification from the dream of a full interrealm, intercommunity multipurpose PKI simplifications in policies, technologies, applications, scope each plane provides experience and value The Four Planes of PKI

  47. Full interrealm PKI - multipurpose, spanning broad and multiple communities, bridges to unite hierarchies, unfathomed directory issues Simple interrealm PKI - multipurpose within a community, operating under standard policies and structured hierarchical directory services PKI-Light - containing all the key components of a PKI, but many in simplified form; may be for a limited set of applications; may be extended within selected communities PKI-Ultralight - easiest to construct and useful conveyance; ignores parts of PKI and not for use external to the institution; learn how to fly, but not a plane... The Four Planes are:

  48. Spectrum of Assurance Levels Signature Algorithms Permitted Range of Applications Enabled Revocation Requirements and Approaches Subject Naming Requirements Treatment of Mobility ... Examples of Areas of Simplification

  49. CP: VeriSign CRL: VeriSign Applications: authentication Mobility: USB dongle Signing: md5RSA Thumbprint: sha1 Naming: X.500 Directory Services needed: I? Deployment: 5,000 medical students PKI-Light example (Texas-Houston)

  50. CP: none CRL: limit lifetime Applications: internal web authentication Mobility: one per system; also password enabled Signing: md5RSA Thumbprint: sha1 Naming: X.500 Directory Services needed: none Deployment: approximately 350,000 over five years PKI-Light (MIT)

More Related