Current Activities in Middleware

Ken Klingenstein,Project Director, Internet2 Middleware InitiativeChief Technologist, University of Colorado at Boulder

Topics

Application requirements - Digital libraries, Grids, IMS, Portals, etc...Early Harvest best practicesEarly AdoptersMace (Middleware Architectural Committee for Education)Experiments: Shibboleth, the Directory of Directories, and EdupersonPKI Medical middlewareInternational 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 directoriesNext-generation portals want common authentication and storage

Partnerships

EDUCAUSECRENGlobus, Legion, etc.CampusesProfessional associations - AACRAO, NACUA, CUMREC

The Early Harvest experiences

Identifiers for people, objects, groups Authentication for people, objects and groupsDirectories to store common informationAuthorization servicesApplications that use all of the aboveComplex design and implementation tradeoffs at technical and policy levels

Early Harvest Outputs

Identifier mappingGood practice documents on middleware web site, to guide campus IT organizationsInformational RFC in JuneMay form part of the basis for an assurance model for higher ed PKI

Identifier Mapping

Map campus identifiers against a canonical set of functional needsFor each identifier, establish its key characteristics, including revocation, reassignment, privileges, and opacityShine a light on some of the shadowy underpinnings of middleware

Major campus identifiers

UUIDStudent and/or emplidPerson registry idAccount login idEnterprise-lan id

NetidEmail addressLibrary/deptl idPublicly visible id (and pseudossn)Pseudonymous id

Identifier Characteristics

Revocation - can the subject ever be given a different value for the identifierReassignment - can the identifier ever be given to another subjectPrivileges - what accesses does the authenticated identifier haveOpacity - 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 basedOthers - challenge-response, biometrics

Typical Good Practices

Have a UUID that is non-revocable, non-reassignable, opaqueNo clear text passwords Precrack new passwords, using foreign dictionaries as well as USConfirm new passwords are different than oldRequire password change if possibly compromisedUse shared secrets or positive photo-id to reset forgotten passwordsPassword strength depends on use...

Typical Interoperability Standards

dc= instead of X.500 for naming of directory suffixes, certificate subjects, etc.use of certain object classfuture standardization of certificate profiles

Directories: Core of the Core

Overall campus directory services modelEnterprise directory design and implementationDepartmental directoriesSecurity and directories

Enterprise directory issues

Schema, referrals and redundancyNamingAttributesReplication and synchronizationGroups

Early Adopters: The Campus Testbed Phase

A variety of roles and missionsCommitment to move implementation forwardProvided some training and facilitated supportDevelop national models of deployment alternativesAddress policy standards

Early Adopter Participants

DartmouthU HawaiiJohns HopkinsUniv of Maryland, BCUniv of MemphisUniv of Michigan

Michigan Tech UnivUniv of PittsburghUniv of Southern CalTufts UnivUniv of Tennessee, Memphis

Primary Goals

to facilitate the campus deployments of core middleware technologiesto identify reasonable approaches - both technical and policy - and design issues and factors that influence institutional selection of a particular approachto enrich the technical contents of Early Harvestto 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 institutionsresearch into options for authorization servicesevaluate new tools and technologies

Basic Approaches

technology sharing and workshopspolicy sharing

• champions• data owners• professional associations - EDUCAUSE, CNI, NACUA, NACUBO,

AACRAO, ALA,

external expertsvendor 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 edMembership - 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 serviceto show the power of coordinationto 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 serversto suggest the service to follow

Edu-person

An objectclass for higher educationContain suggested attributes for instructional, research and administrative inter-institutional usePresumes campuses to add local person objectclass.A joint effort of EDUCAUSE and I2

edu-person 0.9a

parent objectclass=inetorgpersonintends to integrate with Grid, IMS, and other upper-middlewareincludes:

• primary affiliation (fac/stu/staff)• enrolledcurrentterm (binary true/false)• withdrawnpreviousterm (binary)• schoolcollegename, (multivalued case ignore strings)

Shibboleth

interinstitutional web authentication and perhaps authorizationuse local credentials for remote services; enable user@ logins; fosters best practices; encourage transition from simple ht controls to LDAP-baseduses SRV records in DNS and several forms of authn; authz via directoriesIBM to analyze, several schools to participate in pilot

Medical middleware

the intersection of higher ed and health care servicesworst case requirements in I/AHIPAA - new privacy and security requirementsmust integrate with higher level objects - CORBA Medwork will consist of problem structuring, technologies, and policy/process issues

International Aspects

identifier agreementsinternational trust modelsshared expertiseworkshop this summer in Europe

Authorization

how an individual’s attributes are carried from an individual or a central store to an applicationmove from a per-application basis to an infrastructural serviceoptions 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/middlewarenet@educren.orgfPKI workGlobus.org