Current Activities in Middleware

Ken Klingenstein,

Project Director, Internet2 Middleware Initiative

Chief Technologist, University of Colorado at Boulder

Topics

Application requirements - Digital libraries, Grids, IMS, Portals, etc...

Early Harvest best practices

Early Adopters

Mace (Middleware Architectural Committee for Education)

Experiments: Shibboleth, the Directory of Directories, and Eduperson

PKI

Medical middleware

International Efforts

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

Partnerships

EDUCAUSE

CREN

Globus, Legion, etc.

Campuses

Professional associations - AACRAO, NACUA, CUMREC

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

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

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

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

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

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

Authentication Options

Password based• Clear text

• LDAP

• Kerberos

Certificate based

Others - challenge-response, biometrics

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

Password strength depends on use...

Typical Interoperability Standards

dc= instead of X.500 for naming of directory suffixes, certificate subjects, etc.

use of certain object class

future standardization of certificate profiles

Directories: Core of the Core

Overall campus directory services model

Enterprise directory design and implementation

Departmental directories

Security and directories

Enterprise directory issues

Schema, referrals and redundancy

Naming

Attributes

Replication and synchronization

Groups

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

Early Adopter Participants

Dartmouth

U Hawaii

Johns Hopkins

Univ of Maryland, BC

Univ of Memphis

Univ of Michigan

Michigan Tech Univ

Univ of Pittsburgh

Univ of Southern Cal

Tufts Univ

Univ of Tennessee, Memphis

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

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

Basic Approaches

technology sharing and workshops

policy sharing• champions

• data owners

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

external experts

vendor interactions

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

A Directory of Directories

an experiment, now encompassing 8 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

Edu-person

An objectclass for higher education

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

Presumes campuses to add local person objectclass.

A joint effort of EDUCAUSE and I2

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)

Shibboleth

interinstitutional 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 SRV records in DNS and several forms of authn; authz via directories

IBM to analyze, several schools to participate in pilot

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

International Aspects

identifier agreements

international trust models

shared expertise

workshop this summer in Europe

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

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 little understood• mobility user interface internal formats

• trust chains revocation policy expression

See Current Issues in PKI on middleware.internet2.edu for details

Where to watch

www.internet2.edu/middleware

net@edu

cren.org

fPKI work

Globus.org