Internet 2 Progress Report Middleware Experiments Renee Woodten

Internet 2 Progress Report Middleware Experiments Renee Woodten Frost Project Manager, Internet 2 Middleware Initiative I 2 Middleware Liaison, University of Michigan ………………. And an ensemble of hundreds

Topics Internet 2 Overview Middleware Overview Directories LDAP Recipe Edu. Person Directory of Directories for Higher Ed Shibboleth PKI Medical Middleware New Opportunities: Video, the Grid, K-12 CUMREC May 14, 2001

Internet 2 Overview Mission: Develop and deploy advanced network applications and technologies, accelerating the creation of tomorrow’s Internet. Goals: • Enable new generation of applications • Re-create leading edge R&E network capability • Transfer technology and experience to the global production Internet CUMREC May 14, 2001

Core Middleware A layer of software between the network and the applications • Authentication - how you prove or establish that you are that identity each time you connect • Identification - the first characteristics of who you (person, machine, service, group) are • Directories - where the rest of an identity’s characteristics are kept • Authorization - what an identity is permitted to do • Security - ie, PKI - emerging tools for security services CUMREC May 14, 2001

Activities Mace - RL “Bob” Morgan (Washington) Early Harvest / Early Adopters - Renee Frost (Michigan) LDAP Recipe - Michael Gettes (Georgetown) Edu. Person - 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 CUMREC May 14, 2001

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) CUMREC May 14, 2001

Early Harvest and Early Adopters Early harvest in the barn… http: //middleware. internet 2. edu/best-practices. html Early adopters aggressively doing deployments http: //middleware. internet 2. edu/earlyadopters Michigan Tech, U Maryland BC, Johns Hopkins, etc http: //www. colorado. edu/committees/Directory. Services/ CUMREC May 14, 2001

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/internet 2/ldap-recipe/ CUMREC May 14, 2001

LDAP Recipe Contents Directory Information Tree Schema Design Directory of Directories for Higher Education (Do. DHE) expectations Schema Design (continued) Schema: How to upgrade it? Password Management Bindings edu. Person attribute discussions Access Control Replication Name Population LDAP filter config file for white pages telephone. Number formatting CHANGELOG CUMREC May 14, 2001

edu. Person 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 CUMREC May 14, 2001

Issues about Upper Class Attributes edu. Person inherits attributes from person, i. Net. Org. Person 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. ) CUMREC May 14, 2001

New edu. Person Attributes edu. Person. Affiliation edu. Person. Primary. Affiliation edu. Person. Org. DN edu. Person. Org. Unit. DN edu. Person. Principal. Name edu. Person. Nickname CUMREC May 14, 2001

edu. Person. Affiliation Multi-valued list of relationships an individual has with institution Controlled vocabulary includes: faculty, staff, student, alum, member, affiliate, employee Applications that use: Do. D, white pages CUMREC May 14, 2001

edu. Person. Primary. Affiliation 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: Do. D, white pages CUMREC May 14, 2001

edu. Person. Principal. Name 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. CUMREC May 14, 2001

Next Steps edu. Person 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@internet 2. edu CUMREC May 14, 2001

A Campus Directory Architecture Border directory Metadirectory Enterprise directory Departmental directories Dir DB Registries OS directories (MS, Novell, etc) Source systems CUMREC May 14, 2001

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 i. Planet license (6, 000 dn’s) Michael Gettes, Georgetown, is the project manager CUMREC May 14, 2001

Do. D Architecture Inputs to Do. DHE Inputs: Local Site View Central Deposit Service Do. D Config Directory Operation Search Operations • Search Drill Down from a list CUMREC May 14, 2001

Inputs Remote Data Sources Remote Site Directories LDAP Oracle Etc… Search Data Filtering & Submit to CDS Do. D Config Central Deposit Systems (CDS) CUMREC May 14, 2001

Inputs: Local Site View Submit final LDIF to CDS using authenticated POST via HTTPS. Local Data Source LDAP Generate LDIF Data Filter LDIF according to local policy. Generate new LDIF for submission. CDS CUMREC May 14, 2001 D O D H E

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 Do. DHE service. CDS handles reconciliation and controls data processing. Can provide feedback. CUMREC May 14, 2001

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. CUMREC May 14, 2001

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

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): CUMREC May 14, 2001

Shibboleth An initiative to analyze & develop mechanisms (architectures, frameworks, protocols & implementations) for inter-institutional web access control Facilitated by Mace (a committee of leading higher ed IT architects) and Internet 2 “Authenticate locally, act globally” is the Shibboleth shibboleth Oriented towards privacy and complements corporate standards efforts Open solution http: //middleware. internet 2. edu/shibboleth Vendor participation - IBM et al CUMREC May 14, 2001

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. . . CUMREC May 14, 2001

Related Work Previous DLF work http: //www. clir. org/diglib/presentations/cnis 99/sld 001. htm OASIS Technical Committee (vendor activity, kicked off 1/2001) http: //www. oasisopen. org/committees/security/index. shtml http: //lists. oasis-open. org/archives/security-services/ UK - Athens and Sparta projects http: //www. jisc. ac. uk/pub 00/sparta_disc. html Spain - rediris project http: //www. rediris. es/app/papi/index. en. html CUMREC May 14, 2001

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! CUMREC May 14, 2001

Development Process 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 CUMREC May 14, 2001

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. CUMREC May 14, 2001

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. . ) CUMREC May 14, 2001

Shibboleth Architecture Concepts - High Level Pass content if user is allowed Authorization Phase Target Web Server Browser Authentication Phase First Access - Unauthenticated Origin Site Target Site CUMREC May 14, 2001

Shibboleth Architecture Concepts (detail) Authentication Authorization Success! Phase Entitlements Attribute Server Ent Prompt Req Ent Web Login Server Target Web Server Browser Auth OK Authentication Second Access - Authenticated Pass entitlements for authz decision Redirectcontent if. Local Web Login Pass User to user is allowed Ask to Unauthenticated First Access -Obtain Entitlements Origin Site Target Site CUMREC May 14, 2001

Shibboleth Architecture Concepts #1 (managing trust) Club Shib Server (holds certs and contracts) Attribute Server Shib htaccess plugin Target Web Server Browser Origin Site Target Site CUMREC May 14, 2001

Internals of the Shibboleth Model: Functions and Standards 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. CUMREC May 14, 2001

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

Descriptions of services 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 CUMREC May 14, 2001

Component Relationship Model ORIGIN TARGETMay 14, 2001 CUMREC

Campus and Resource Requirements To Participate in Shibboleth, a site must have: • Campus-wide authentication service • Campus-wide identifier space (EPPN) • Implementation of Edu. Person objectclass • Ability to generate attributes (eg “active member of the community”) CUMREC May 14, 2001

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) CUMREC May 14, 2001

Charge -- OASIS Security Services Technical Committee Standardize: • an XML format for "assertions” (authentication, 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 CUMREC May 14, 2001

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 CUMREC May 14, 2001

Project Status/Next Steps Requirements and Scenarios document nearly finished IBM & Mace-Shibboleth refining architecture & evaluating issues IBM intends to develop an Apache web module Internet 2 intends to develop supporting materials (documentation, installation, etc) and web tools (for htaccess construction, filter & 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 - Internet 2 Fall Member Meeting 2001 CUMREC May 14, 2001

Shibboleth, edu. Person, and Middleware Inputs & Outputs everything else Licensed Resources Grids OKI Embedded App Security JA-SIG & u. Portal Inter-realm calendaring Shibboleth, edu. Person, Affiliated Dirs, etc. Campus web sso Enterprise Directory Enterprise Authentication futures Enterprise Auth. Z Legacy Systems CUMREC May 14, 2001

Internet 2 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 CUMREC May 14, 2001

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 CUMREC May 14, 2001

HEPKI-PAG David Wasley, UCOP, prime mover Draft certificate policy for a campus HEBCA certificate policy FERPA State Legislatures Gartner Group Decision Maker software CUMREC May 14, 2001

Medical Middleware Unique requirements - HIPAA, disparate relationships, extended community, etc. Unique demands - 7 x 24, visibility PKI seen as a key tool Mace-med recently formed to explore the issues CUMREC May 14, 2001

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. CUMREC May 14, 2001

The applications view of medical upperware Client (in this scenario) Server (in this scenario) VA Clinical System Do. D Clinical System Request lab data, This Soldier, this time frame Who’s asking? What role? What is need to know? Resource Access Decision (RAD) Who is this person? Who knows this person? Person Identification Service (PIDS) Where is lab info on this. Convert to server’s terms person? Health Information Locator Service (HILS) Request observation Clinical Observation Access Service (COAS) Terminology Query Service (TQS) outbound CUMREC May 14, 2001

The enterprise architect view of medical middleware Medical Administrative Systems Research Systems Hospital Administrative Systems Internet App dir LAN dir Institutional Student Financial Personnel Systems Person registry Border Directory Enterprise directory Authentication Services Peer institutions Corporate collaborators PKI Authorization Services Federal State Gov’ts CUMREC May 14, 2001

Video A variety of tools - vic/vat, H. 323, MPEG 2, HDTV Point-to-point and MCU options H. 323 desktop video within reach at physical layer Lacks identifiers and authentication EPPN and Shibboleth-type flow could address CUMREC May 14, 2001

K-12 The killer app may be a spreadsheet and resource discovery Directories to locate information Directories to store experiments Technology isn’t enough CUMREC May 14, 2001

More information Early Harvest / Early Adopters: http: //middleware. internet 2. edu/earlyadopters/ Mace: middleware. internet 2. edu LDAP Recipe: http: //www. georgetown. edu/giia/internet 2/ldaprecipe/ Edu. Person: www. educause. edu/eduperson Directory of Directories: middleware. internet 2. edu/dodhe Shibboleth: middleware. internet 2. edu/shibboleth HEPKI-TAG: www. educause. edu/hepki HEPKI-PAG: www. educause. edu/hepki Medical Middleware: web site to follow Opportunities: video, the GRID, K-12 CUMREC May 14, 2001