Post on 24-Jan-2016
description
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