Internet2 Middleware Initiatives: Early Harvest to Early Adopters and Beyond

Internet2 Middleware Initiatives:Early Harvest to Early Adopters and

Beyond

Renee Woodten Frost

Project Manager, Middleware Early Adopters, Internet2

Project Liaison, University of Michigan

May 15, 2000

Middleware Initiatives

Topics

Internet2 Overview

Middleware

Application requirements - Digital libraries, Grids, IMS, Portals

Early Harvest best practices

Early Adopters

Mace (Middleware Architectural Committee for Education)

Experiments: the Directory of Directories, Eduperson, and Shibboleth

PKI

Medical middleware

International Efforts

Middleware Initiatives

Internet2 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

Middleware Initiatives

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

Middleware Initiatives

Application Requirements

Digital libraries need scalable, interoperable authentication and authorization.

The Grid as the new paradigm for a computational resource, with Globus the middleware, including security, location and allocation of resources, scheduling, etc. built on top of campus infrastructures.

Instructional Management Systems (IMS) need authentication and directories

Next-generation portals want common authentication and storage

Middleware Initiatives

Partnerships

EDUCAUSE

CREN

Globus, Legion, etc.

Campuses

Professional associations - AACRAO, NACUA, etc.

Middleware Initiatives

The Early Harvest experiences

Identifiers for people, objects, groups

Authentication for people, objects and groups

Directories to store common information

Authorization services

Applications that use all of the above

Complex design and implementation tradeoffs at technical and policy levels

Middleware Initiatives

Early Harvest Outputs

Identifier mapping

Good practice documents on middleware web site, to guide campus IT organizations

Informational RFC in June

May form part of the basis for an assurance model for higher ed PKI

Middleware Initiatives

Identifier Mapping

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

Middleware Initiatives

Major campus identifiers

UUID

Student and/or emplid

Person registry id

Account login id

Enterprise-lan id

Netid

Email address

Library/deptl id

Publicly visible id (and pseudossn)

Pseudonymous id

Middleware Initiatives

Identifier Characteristics

Revocation - can the subject ever be given a different value for the identifier

Reassignment - can the identifier ever be given to another subject

Privileges - what accesses does the authenticated identifier have

Opacity - is the real world subject easily deduced from the identifier - privacy and use issues

Middleware Initiatives

Identifier relationships

Person registry ID

Email address

Library ID

Acct login Pseudo ID

Student ID

PubVis ID

Enterprise-LAN ID

DepartmentalIDs

UUIDEmpl ID

ISO card ID

Middleware Initiatives

Authentication Options

Password based• Clear text

• LDAP

• Kerberos

Certificate based

Others - challenge-response, biometrics

Middleware Initiatives

Typical Good Practices

Have a UUID that is non-revocable, non-reassignable, opaque

No clear text passwords

Precrack new passwords 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

Middleware Initiatives

Typical Interoperability Standards

Use of dc (domain component) instead of X.500 for naming of directory suffixes, certificate subjects, etc.

Use of certain object class

Future standardization of certificate profiles

Middleware Initiatives

Directories: Core of the Core

Overall campus directory services model

Enterprise directory design and implementation

Departmental directories

Security and directories

Middleware Initiatives

Enterprise directory issues

Schema, referrals and redundancy

Naming

Attributes

Replication and synchronization

Groups

Middleware Initiatives

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

Middleware Initiatives

Early Adopter Participants

Dartmouth

Univ of Hawaii

Johns Hopkins Univ

Univ of Maryland, BC

Univ of Memphis

Univ of Michigan

Michigan Tech Univ

Univ of Pittsburgh

Univ of Southern California

Tufts Univ

Univ of Tennessee, Memphis

Middleware Initiatives

Primary Goals

To facilitate the campus deployments of core middleware technologies

To identify reasonable approaches - both technical and policy - and design issues and factors that influence institutional selection of a particular approach

To enrich the technical contents of Early Harvest

To inform larger community (NSF, Education, NIH, etc) of requirements for deployment and interoperability

Middleware Initiatives

Secondary Goals

Explore medical middleware issues• Generic - how is this expressed in the core deployment

• Specific - what medical data structures need integration into campus environment

Outreach to encourage other institutions

Research into options for authorization services

Evaluate new tools and technologies

Middleware Initiatives

Basic Approaches

Technology sharing and workshops

Policy sharing• champions

• data owners

• professional associations - EDUCAUSE, CUMREC, CNI, NACUA, NACUBO, AACRAO, ALA

External experts

Vendor interactions

Middleware Initiatives

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), Mark Mara (Cornell), Mark Poepping (CMU)

Current working Groups• DIR - eduperson, the Uber-directory experiment• PKI - campus operational issues, trust models, fPKI involvement• Shibboleth - inter-institutional resource sharing

Middleware Initiatives

A Directory of Directories

An experiment, now encompassing 10 schools, to build a combined directory search service

• to show the power of coordination

• to show the existing barriers to cooperation– standard object classes- standard display formats- standard meta-data

• to investigate load and scaling issues - on the clients and the servers

• to suggest the service to follow

Middleware Initiatives

Edu-person

An objectclass for higher education

Contains suggested attributes for instructional, research and administrative inter-institutional use

Presumes campuses to add local person objectclass.

A joint effort of EDUCAUSE and I2

Middleware Initiatives

Edu-person 0.9a

Parent objectclass=inetorgperson

Intends to integrate with Grid, IMS, and other upper-middleware

Includes:• primary affiliation (fac/stu/staff)

• enrolledcurrentterm (binary true/false)

• withdrawnpreviousterm (binary)

• schoolcollegename, (multivalued case ignore strings)

Middleware Initiatives

Shibboleth

Inter-institutional web authentication and perhaps authorization

Use local credentials for remote services; enable user@ logins; fosters best practices; encourage transition from simple ht controls to LDAP-based

Uses records in DNS and several forms of authentication; authorization via directories

IBM to analyze, several schools to participate in pilot

Middleware Initiatives

Authorization

How an individual’s attributes are carried from an individual or a central store to an application

Move from a per-application basis to an infrastructural service

Options include• Kerberos tickets

• LDAP calls

• RPC’s

• long-term certificates

• attribute certificates

Middleware Initiatives

PKI

Public Key Certificates are a remarkably simple and powerful tool for

• signing documents, authentication, encrypting email, building secure channels across the Internet, non-repudiation, conveying authorizations, and more

Infrastructure to support this is little understood • mobility, user interface, internal formats, trust chains, revocation,

policy expression

Middleware Initiatives

Uses for Certificates

Authentication and pseudo-authentication

Signing docs

Encrypting docs and mail

Non-repudiation

Secure channels across a network

Authorization and attributes

and more...

Middleware Initiatives

Certificate Profiles

Per field description of certificate contents - both standard and extension fields, including criticality flags

Syntax of values permitted per field

Semantics specified

Spreadsheet format by R. Moskowitz, XML and ANS alternatives for machine use

Centralized repository for higher ed being set up

Middleware Initiatives

Certificate Policies

Legal responsibilities and liabilities (indemnification issues)

Operations of Certificate Management systems

Best practices for core middleware

Assurance levels - varies according to I/A processes and other operational factors

Middleware Initiatives

Certificate Practice Statements

Operational aspects that allow lawyers to decide who to trust

must cover I/A, Cert Management, underlying operations

Middleware Initiatives

PKI Activities

DLF: UCOP, Columbia, soon Minnesota

FPKI (http://csrc.nist.gov/pki/twg/welcome.html)

PKI for NGI, Globus

net@edu within EDUCAUSE

CREN CA

In-sources - MIT, Michigan

Out-sources - Pittsburgh, Texas

PKIforum

W2K

Middleware Initiatives

Next Steps

PKI Labs• long-term research agenda, includes path math, open standards

and reference implementations

• ATT catalyst funding with other investments expected

• a national advisory board

• RFP next month

Net@edu• Fed-ed meetings

• workshops

Middleware Initiatives

Next Steps

HEPKI - Technical Activities Group• universities actively working on technical issues

• topics include kerberos-PKI integration, public domain CA, profiles

• will sponsor regular conference calls, email archives

HEPKI - Policy Activities Group• universities actively deploying PKI topics include certificate

policies, RFP sharing, interactions with state governments

• will sponsor regular conference calls, email archives

Middleware Initiatives

Medical Middleware

The intersection of higher ed and health care services

Worst case requirements in I/A

HIPAA - new privacy and security requirements

Must integrate with higher level objects - CORBA Med

Work will consist of problem structuring, technologies, and policy/process issues

Middleware Initiatives

International Aspects

Identifier agreements

International trust models

Shared expertise

Workshop this summer in Europe

Middleware Initiatives

Where to watch

www.internet2.edu/middleware

net@edu

www.cren.org

fPKI work

www.Globus.org