1 / 41

Middleware and Muddleware: A Progress Report

Middleware and Muddleware: A Progress Report. Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder. Internet1 to Internet2 Challenges. Video Sci apps Multimodia . Telnet web email. Directories Security Agents. IP v4

barto
Download Presentation

Middleware and Muddleware: A Progress Report

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 and Muddleware:A Progress Report Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder

  2. Internet1 to Internet2 Challenges • Video • Sci apps • Multimodia • Telnet • web • email • Directories • Security • Agents • IP v4 • DNS • QoS • Multicast • IPv6

  3. Early Harvest results CIO study group and dissemination Next steps PKI - products and policies .eduorgperson tools Agenda

  4. eh? NSF goals best practices accelerate campus progress inform NSF Sept 23-24 Denver Workshop Dissemination Early Harvest Workshop

  5. Daniel Arrasjid SUNY, Buffalo Bob Brentrup Dartmouth Keith Brown Duke Mark Bruhn Indiana *Steve Carmody Brown Alan Crosswell Columbia Bill Doster Michigan *Michael Gettes Georgetown Frank Grewe Minnesota Annette Haworth Reading, England Keith Hazelton Wisconsin Paul Hill MIT Steve Kellogg Penn State ** Bob Morgan Washington * Mark Poepping Carnegie-Mellon David Wasley California President's Office Norm Wiseman JISC Steve Worona Cornell Participants

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

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

  8. Major campus identifiers • UUID • Person registry id • Account login/ Netid • Email address • Library/deptl id • Publicly visible id (and pseudossn) • Pseudononmyous id

  9. Identifier Space Person Registry UUID Acct Login PVI Pseudononymous Email address Departmental ids

  10. UUID • Purpose - primary internal identifier, used for file access, group membership • Characteristics - machine readable, centrally provided, eternal, large capacity

  11. Person registry id • Purpose - resolve ambiguities on identity; critical to distributed and outreaching activities • Characteristics - opaque, centrally provided but locally administered, eternal, very large capacity, • Very labor intensive; resolver is human • Stored in a database, not a directory • Keyed off of UUID where possible

  12. Account login/Net • Purpose - login to campus resources (email, net) • Characteristics - human readable, centrally provided, resolved via authentication process, not necessarily eternal, limited capacity, extensible to groups

  13. Email Address • Purpose - email, human-friendly global identifier • Characteristics - human-readable, centrally provided, resolved via sendmail or LDAP, • Less agreement - persistence

  14. Departmental Id • Purpose • Characteristics

  15. Publicly visible identifier • Purpose - post grades publicly, resolve directory inquiries • Characteristics - human readable but dumb, resolved through directory, centrally afforded, need not be eternal,

  16. Pseudononymous identifier • Purpose - access academic resources such as Libraries • Characteristics - centrally provided, machine readable, • Uncertain - persistence, capacity

  17. Cuttings: Authentication • user password management - crack, change, compromise • central password management - change, audit, • first password assignment - secure delivery • policies and practices - scope of use

  18. User password management • Good practices • Precrack new passwords • 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 aging seems to do more harm than good

  19. First password assignment • Good practices • USmail a one-time password • 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. • Uncommon approaches

  20. Beyond Passwords • Shared secrets • Challenge-response (S/Key, Smart Card) - for certain secure accounts • X.509 - no one using yet • Biometrics - no one using yet

  21. Cuttings: Directories • Overall campus directory services model • Enterprise directory design and implementation • Departmental directories • Security and directories

  22. Overall Campus Directory Structure Border directory Metadirectory Enterprise directory Departmental directories OS directories (MS, Novell, etc) Dir DB

  23. Key directory issues • legacies -DCE, NDS, NT, etc. • applications - Peoplesoft, SAP • future application development platforms • authority and data ownership

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

  25. Schema Issues • Overall logical design • Inheritance of policy and attributes • Referral to other parts of the tree • Delegation, replication, synchronization

  26. Schema Best Practices • People, machines, services • Be very flat in people space • Create a “campus person” • Keep accounts as attributes, not as an ou • Replication not a primary driver in schema • Group policies not a primary driver in schema • New DNS hack to serve directory locations • No trolling permitted; more search than read

  27. Naming Issues • RDN • Other keys • Preserving name space

  28. Naming Best Practices • dc= as a name versus c=, ou= • RDN may well be UUID

  29. Attribute Best Practices • 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.

  30. Groups Best Practices • Limit size and use (e.g. no email) but allow user creation • Web access to group lists avoids multivalue problems • Supply key institutional groups (class lists, Y2K coords) centrally • Performance issues need to be watched

  31. Groups Uncertainties • no consensus on where to store • as a schema attribute for individuals • as a separate entry within overall hierarchy • some variations on naming • within user name space • may augment with group or owner indicator

  32. CIO Study Group • Not the usual suspects • Commitment to move implementation forward • Provided some training and facilitated support • RFP this month

  33. Dissemination • Web Site • Educause articles • Presentation at I2 Fall meeting, Educause Conf, CNI • Regional workshops

  34. Next steps • PKI • .eduorgperson • killer glue • viable products

  35. PKI Components • X.509 certificates, PKCS • CA’s and CRLS • profiles, policies and practices • trust models • viable products

  36. X.509 and PKCS • X.509 defines certificates, trust models, and uses • PKCS defines critical implementation details - eg specific encryption algorithm choices, key formats for portability, etc. • PKCS is RSA-oriented; patent burning party next year.

  37. Higher Ed PKI Open Issues • profiles - common certificate templates for standard academic uses • policies - stating eligibilities, roles and responsibilities • practices - standard specific operating conventions • trust models - hierarchy, bridge, none; on and off-campus • viable products - cost, flexible, mobility, integration with embedded bases, public domain/open source alternatives • research opportunities - apps that use policies

  38. PKI process issues • how should planning and direction be done? • How can the research opportunities be realized?

  39. .eduorgperson • Is there a need for a multicampus subschema • What is the right granularity - BigN, CSG, I2, edu • How to define and populate to minimize redundancies • Is there an oid arc for education/research

  40. Killer Glue • Interoperable web page authentication - an Apache module • Interoperable secure directories bindings • Retooling apps to use @ identifiers • Enable interinstitutional resource sharing • Encourage transition from htaccess protection to LDAP protection • Corporate help?

  41. Vendor discounts/ public domain • Directory and metadirectory software • DCE • PKI • fPKI work - • http://csrc.nist.gov/pki/twg/welcome.html • Van Dyke and Associates; Cygnacom public domain pieces • Jonah from IBM

More Related