1 / 55

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. Activities. Mace - RL “Bob” Morgan (Washington)

jeneva
Télécharger la présentation

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. 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), Jack Buchanan (UT, Memphis) • Opportunities - video, the GRID, K-12 CIC AIS Directors Spring 2001

  3. 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 (NCSA) CIC AIS Directors Spring 2001

  4. 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 • Michigan Tech, U Maryland BC, Johns Hopkins, etc • http://www.colorado.edu/committees/DirectoryServices/ CIC AIS Directors Spring 2001

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

  6. LDAP Recipe Contents • Directory Information TreeSchema DesignDirectory of Directories for Higher Education (DoDHE) expectationsSchema Design (continued)Schema: How to upgrade it?Password ManagementBindingseduPerson attribute discussionsAccess ControlReplicationName PopulationLDAP filter config file for white pagestelephoneNumber formattingCHANGELOG CIC AIS Directors Spring 2001

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

  8. 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 CIC AIS Directors Spring 2001

  9. eduPersonAffiliation eduPersonPrimaryAffiliation eduPersonOrgDN eduPersonOrgUnitDN eduPersonPrincipalName eduPersonNickname New eduPerson Attributes CIC AIS Directors Spring 2001

  10. 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 eduPersonAffiliation CIC AIS Directors Spring 2001

  11. Single-valued attribute that would be the status put on a name badge at a conference Controlled vocabulary includes: faculty, staff, student, alum, member, affiliate, employee Applications that use: DoD, white pages eduPersonPrimaryAffiliation CIC AIS Directors Spring 2001

  12. 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 understand the reassignment policy. eduPersonPrincipalName CIC AIS Directors Spring 2001

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

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

  15. 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, is the project manager CIC AIS Directors Spring 2001

  16. DoD Architecture • Inputs to DoDHE • Inputs: Local Site View • Central Deposit Service • DoD Config Directory • Operation • Search Operations • Search Drill Down from a list CIC AIS Directors Spring 2001

  17. Inputs Remote Site Directories Remote Data Sources LDAP Oracle Etc… Search Data Filtering & Submit to CDS DoD Config Central Deposit Systems (CDS) CIC AIS Directors Spring 2001

  18. CDS Inputs: Local Site View Submit final LDIF to CDS using authenticated POST via HTTPS. Local Data Source LDAP Filter LDIF according to local policy. Generate new LDIF for submission. DODHE Generate LDIF Data CIC AIS Directors Spring 2001

  19. Inputs: Why this way? • Standardized input is LDIF • Could be XML but few products generate XML now (01/2001) • Could use Metamerge Integrator as filter and submission mechanism • Site always submits full dataset. No worry of reconciling. Easier site participation in the DoDHE service. • CDS handles reconciliation and controls data processing. Can provide feedback. CIC AIS Directors Spring 2001

  20. Metadirectories: Metamerge • www.architech.no is now Metamerge • 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. CIC AIS Directors Spring 2001

  21. Metamerge Features • GUI development environment • NOT a Meta-Directory, but a tool to build same functionality • Various Languages: JavaScript, Java, Perl, Rexx, etc… • Various Parsers: XML, LDIF, CSV, Script Interface, etc … • for input and output • Various Connectors: COMport, Files, HTTP, HTTPserver, FTP, LDAP, JDBC, Oracle and more … • The product is ALL Java CIC AIS Directors Spring 2001

  22. This begs the following … • If you were given both this Metamerge LDIFTransformer and a Perl script that is the basis for the same functionality – each need to be customized for local purposes – which appears more attractive to you? • Answer: from querying various institutions on this question the common response, nearly 100%, is that use of Metamerge is good, interesting and yields other possibilities not likely with just a Perl script. So, the DoDHE will progress assuming Metamerge. If your institution would like to do something different, then you are welcome to do so. Hopefully a common solution will have benefits beyond a custom solution. CIC AIS Directors Spring 2001

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

  24. Shibboleth • An initiative to analyze and develop mechanisms(architectures, frameworks, protocols and implementations) for inter-institutional web access control • Facilitated by Mace (a committee of leading higher ed IT architects) and Internet2 • “Authenticate locally, act globally” the Shibboleth shibboleth • Oriented towards privacy and complements corporate standards efforts • Open solution • http://middleware.internet2.edu/shibboleth • Vendor participation - IBM et al CIC AIS Directors Spring 2001

  25. 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... CIC AIS Directors Spring 2001

  26. Related Work • Previous DLF work • http://www.clir.org/diglib/presentations/cnis99/sld001.htm • OASIS Technical Committee (vendor activity, kicked off 1/2001) • http://www.oasis-open.org/committees/security/index.shtml • http://lists.oasis-open.org/archives/security-services/ • UK - Athens and Sparta projects • http://www.jisc.ac.uk/pub00/sparta_disc.html • Spain - rediris project • http://www.rediris.es/app/papi/index.en.html CIC AIS Directors Spring 2001

  27. Assumptions • “authenticate locally, act globally” the Shibboleth shibboleth • Leverage vendor and standards activity wherever possible • Disturb as little of the existing campus infrastructure as possible • Work with common, minimal authorization systems (eg htaccess) • Encourage good campus behaviors • Learn through doing • Create a marketplace and reference implementations • We will not be another dead guppy • Protect Personal Privacy! CIC AIS Directors Spring 2001

  28. Scenarios leading to requirements Establish model architectures for common services and scenario-specific services Develop service and protocol requirements Identify service options/begin protocol development Produce open implementations of missing service components; provide external services as needed Development Process CIC AIS Directors Spring 2001

  29. 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 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 Spring 2001

  30. Architectural Model • Local Authentication • Local Entity Willing to Create and Sign Entitlement • Set of assertions about the user (Attribute/value pairs) • User has control over disclosure • Identity optional • “active member of community”, “Associated with Course XYZ” • Target responsible for Authorization • Rules engine • Matches contents of entitlements against ruleset associated with target object • Cross Domain Trust • Previously created between origin and target • Perhaps there is a contract (information providers..) CIC AIS Directors Spring 2001

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

  32. 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 Spring 2001

  33. Shibboleth ArchitectureConcepts #1 (managing trust) Club Shib Server (holds certs and contracts) Attribute Server Shib htaccess plugin Target Web Server Browser Origin Site Target Site CIC AIS Directors Spring 2001

  34. Campus and Resource Requirements • To Participate in Shibboleth, a site must have: • Campus-wide authentication service • Campus-wide identifier space (EPPN) • Implementation of EduPerson objectclass • Ability to generate attributes (eg “active member of the community”) CIC AIS Directors Spring 2001

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

  36. There are component services that are assumed to exist already on campuses There are new functional services that must be implemented There are new protocols that must be developed There are data and metadata definitions that must be standardized. Internals of the Shibboleth Model:Functions and Standards CIC AIS Directors Spring 2001

  37. Internals of the Shibboleth Model:Services, standards, protocols Identifier privacy engine Institutional shib key distribution service Where from service Web access control service Inter-realm information exchange protocols for authentication and authorization OASIS XML Standard Credential Factory Local authentication service Web SSO service Local Shibboleth control point Local attribute server CIC AIS Directors Spring 2001

  38. Shibboleth Components CIC AIS Directors Spring 2001

  39. local authentication server - assumed part of the campus environment web sso server - typically works with local authn service to provide web single sign-on resource manager proxy, resource manager - may serve as control points for actual web page access attribute authority - assembles/disassembles/validates signed XML objects using attribute repository and policy tables attribute repository - an LDAP directory, or roles database or…. Where are you from service - one possible way to direct external users to their own local authn service attribute mapper - converts user entitlements into local authorization values PDP - policy decision points - decide if user attributes meet authorization requirements SHAR - Shibboleth Attribute Requestor - used by target to request user attributes Descriptions of services CIC AIS Directors Spring 2001

  40. Component Relationship Model TARGET ORIGIN CIC AIS Directors Spring 2001

  41. Authorization Attributes • Typical Assertions in the Higher Ed Community • EPPN=gettes@georgetown.edu • “active member of the community” • “active in course X” • member of group “georgetown.giia • ? • Signed by the institution! (optional in OASIS, required in Shib) CIC AIS Directors Spring 2001

  42. Isn’t This What LDAP Does? • Since this doesn’t exist yet, it can do a lot more than LDAP! (-: • XML is so extensible that this is the last protocol that we’ll ever need! (-: • OK, tell me really….. • The key here is the CONTROLLED dissemination of attribute information, based on multiple factors. CIC AIS Directors Spring 2001

  43. Charge -- OASIS Security Services Technical Committee • Standardize: • an XML format for "assertions” (authentication, authorization, authorization decision, access yes/no) • (maybe) a (stateless ?) request/response protocol for obtaining assertions • transport bindings for this protocol to HTTP, S/MIME, RMI, etc. • This will be accompanied by requirements/scenarios, compliance info, security considerations, etc • Out of Scope… • How authentication is done • Defining specific attributes (eg “member of community”) • Establishing trust between origin and target • Note.. • Inter-product, not explicitly inter-domain CIC AIS Directors Spring 2001

  44. 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 - May, 2001 • Coding of a prototype begins June 1 • Pilot sites start-up - Aug, 2001 • Public demo of the prototype by the pilots - Internet2 Fall Member Meeting 2001 CIC AIS Directors Spring 2001

  45. 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 Spring 2001

  46. 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 CIC AIS Directors Spring 2001

  47. HEPKI-TAG • Chaired by Jim Jokl, Virginia • Certificate profiles • survey of existing uses • development of standard presentation • identity cert standard recommendation • Mobility options – IETF SACRED scenarios • Public domain software alternatives CIC AIS Directors Spring 2001

  48. HEPKI-PAG • David Wasley, UCOP, prime mover • Draft certificate policy for a campus • HEBCA certificate policy • FERPA • State Legislatures • Gartner Group Decision Maker software CIC AIS Directors Spring 2001

  49. Medical Middleware • Unique requirements - HIPAA, disparate relationships, extended community, etc. • Unique demands - 7x24, visibility • PKI seen as a key tool • Mace-med recently formed to explore the issues CIC AIS Directors Spring 2001

  50. The complex challenges of academic medical middleware • Intra-realm issues - multiple vendors, proprietary systems, evolving regulations • Enterprise issues - security, directories, authorization; balance of institutional and medical enterprises • Inter-realm issues - standards, gateways, common operational processes and policies, performance • Multiple communities of interest - institutional, medical center, affiliated hospitals, state and federal regulatory and certification organizations, insurance companies, medical researchers, etc. CIC AIS Directors Spring 2001

More Related