1 / 64

Internet2 Middleware Activities Progress

Internet2 Middleware Activities Progress. Renee Woodten Frost Project Manager, Internet2 Middleware Initiative I2 Middleware Liaison, University of Michigan ………………. And an ensemble of hundreds. MACE and the working groups NSF catalytic grant and meeting Early Adopters

ivanbritt
Download Presentation

Internet2 Middleware Activities Progress

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. Internet2 Middleware Activities Progress Renee Woodten Frost Project Manager, Internet2 Middleware Initiative I2 Middleware Liaison, University of Michigan ………………. And an ensemble of hundreds

  2. 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 CIC AIS Directors Fall 2001

  3. Activities • Mace - RL “Bob” Morgan (Washington) • Early Harvest / Early Adopters - Renee Frost (Michigan) • LDAP Recipe - Michael Gettes (Georgetown) • EduPerson and EduOrg - Keith Hazelton (Wisconsin) • Directory of Directories for Higher Ed - 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), Jack Buchanan (UT Health Science Ctr) • NSF Middleware Initiative – core middleware, pki, video, the GRID CIC AIS Directors Fall 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 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... CIC AIS Directors Fall 2001

  5. 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 CIC AIS Directors Fall 2001

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

  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 Internet2 middleware site • http://middleware.internet2.edu/earlyadopters/ • Participants: Dartmouth, Hawaii, Johns Hopkins, Maryland-Baltimore County, Memphis, Michigan Tech, Michigan, Pittsburgh, Tennessee Health Science Center, Tufts, USC CIC AIS Directors Fall 2001

  8. Early Adopters Business Case • Middleware Business Case and Writer’s Guide version 1.0 • http://middleware.internet2.edu/earlyadopters/ • Review and send comments to: • MW-buscase-comments@internet2.edu CIC AIS Directors Fall 2001

  9. 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 CIC AIS Directors Fall 2001

  10. A Map of Middleware CIC AIS Directors Fall 2001

  11. 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 CIC AIS Directors Fall 2001

  12. 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 CIC AIS Directors Fall 2001

  13. 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 CIC AIS Directors Fall 2001

  14. The Major Projects • eduPerson and eduOrg (mace-dir) • the Directory of Directories for Higher Education (DoDHE) • Shibboleth (mace-shibboleth) and Webiso (mace-webiso) • Directories • metadirectories • groups • affiliated directories • HEBCA and PKI-Light (HEPKI-PAG and HEPKI-TAG) • PKI Labs at Dartmouth and Wisconsin • Videoconferencing and video on demand (vidmid) • OKI, JA-SIG and the Grids CIC AIS Directors Fall 2001

  15. 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 now done; one or two revisions anticipated eduPerson CIC AIS Directors Fall 2001

  16. eduPerson 1.0 • parent objectclass=inetOrgPerson • includes: • affiliation (multi-valued) • primary affiliation (faculty/student/staff) • orgUnitDN (string) • nickname (string) • ePPN (identifier, user@securitydomain) • version 1.5 and beyond will contain other shared attributes CIC AIS Directors Fall 2001

  17. 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 interface issues - searching large name spaces with limits by substring, location, affiliation, etc... • to suggest the service to follow • Sun donation of server and 6 million DNs • http://dodhe.internet2.edu/dodhe/ CIC AIS Directors Fall 2001

  18. 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): CIC AIS Directors Fall 2001

  19. Shibboleth • inter-institutional 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 and architecture done; coding has commenced with alpha code due in January, 2002 to pilot sites • coding and design teams feature IBM/Tivoli, CMU, and the Ohio State University • strong partnership with IBM to develop and deploy • http://middleware.internet2.edu/shibboleth/ CIC AIS Directors Fall 2001

  20. Stage 1 - Addressing Three Scenarios • 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 unique identifiers (e.g. name) • Taken individually, each of these situations can be solved in a variety of straightforward ways. • Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy. CIC AIS Directors Fall 2001

  21. Shibboleth ArchitectureConcepts - High Level Browser Pass content if user is allowed Target Web Server Authorization Phase Authentication Phase First Access - Unauthenticated Target Site Origin Site CIC AIS Directors Fall 2001

  22. Shibboleth ArchitectureConcepts (detail) Browser Target Web Server Authorization Phase Authentication Phase Success! Entitlements Attribute Server Ent Prompt Req Ent Second Access - Authenticated Auth OK Pass entitlements for authz decision Web Login Server Redirect User to Local Web Login Pass content if user is allowed Authentication Ask to Obtain Entitlements First Access - Unauthenticated Target Site Origin Site CIC AIS Directors Fall 2001

  23. Shibboleth Architecture - Components and Flow CIC AIS Directors Fall 2001

  24. 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 CIC AIS Directors Fall 2001

  25. Project Status • Architecture definition finished (v0.9+) • Design/Programming now Underway • Team membership drawn from IBM/Tivoli, CMU, Ohio State • First Face-to-Face meeting on Sept 27, 28 at CMU • First Set of Pilot Sites Selected • Chosen to test all 3 scenarios • UK participation • Timeline for programming, piloting available end of October CIC AIS Directors Fall 2001

  26. A Campus Directory Architecture Border directory Metadirectory Enterprise directory OS directories (MS, Novell, etc) Departmental directories Dir DB Registries Source systems CIC AIS Directors Fall 2001

  27. 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 CIC AIS Directors Fall 2001

  28. Directories – Group Management • Best practices in the use of core middleware to meet the authorization and messaging needs of applications • Initial foci are: • the conduct of a survey of several organizations' practices in this area and • investigations into meaningful definitions of, and productive ways of representing and operating on, "groups", "affiliations", "roles", and "correlations". • Groups Practices Survey • http://middleware.internet2.edu/dir/groups/ CIC AIS Directors Fall 2001

  29. 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) CIC AIS Directors Fall 2001

  30. 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 CIC AIS Directors Fall 2001

  31. 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. CIC AIS Directors Fall 2001

  32. 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 CIC AIS Directors Fall 2001

  33. 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? CIC AIS Directors Fall 2001

  34. 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? CIC AIS Directors Fall 2001

  35. 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 CIC AIS Directors Fall 2001

  36. 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: CIC AIS Directors Fall 2001

  37. 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 CIC AIS Directors Fall 2001

  38. 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) CIC AIS Directors Fall 2001

  39. 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) CIC AIS Directors Fall 2001

  40. D. Wasley’s PKI Puzzle CIC AIS Directors Fall 2001

  41. 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... CIC AIS Directors Fall 2001

  42. Implementation varies by contexts/components CIC AIS Directors Fall 2001

  43. 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 CIC AIS Directors Fall 2001

  44. 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.) CIC AIS Directors Fall 2001

  45. 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 CIC AIS Directors Fall 2001

  46. Extension fields • Examples - authorization/subject subcodes, key usage, LDAP URL, CRL distribution points, etc. • Key usage is very important - for digital signatures, non-repudiation, key or data encipherment, etc. • Certain extensions can be marked “critical” - if an app can’t understand the extension, then it doesn’t use the cert • Requires profiles to document, and great care... CIC AIS Directors Fall 2001

  47. 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 • Certificate Authority software or outsource options • Homebrews • Open Source - OpenSSL, OpenCA, Oscar • Third party - Baltimore, Entrust, etc. • OS-integrated - W2K, Sun/Netscape, etc. CIC AIS Directors Fall 2001

  48. 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 CIC AIS Directors Fall 2001

  49. Certificate Policies (CP) and Practices Statements (CPS) • Policies: legal responsibilities and liabilities (indemnification issues) • Operations of certificate management systems • Will hopefully be somewhat uniform across the community • Assurance levels - varies according to I/A processes and other operational factors • Practices - site-specific details of operational compliance with a cert policy • A Policy Management Authority (PMA) determines if a CPS is adequate for a given CP. CIC AIS Directors Fall 2001

  50. Inter-organizational trust model components • verifying sender-receiver assurance by finding a common trusted entity • must traverse perhaps branching paths to establish trust paths • must then use CRLs etc. to validate assurance • if policies are in cert payloads, then validation can be quite complex • delegation makes things even harder • Hierarchies vs. Bridges • a philosophy and an implementation issue • the concerns are transitivity and delegation • hierarchies assert a common trust model • bridges pairwise agree on trust models and policy mappings CIC AIS Directors Fall 2001

More Related