Transcript No Slide Title

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
Netid
Student and/or emplid
Email address
Person registry id
Library/deptl id
Account login id
Publicly visible id (and pseudossn)
Enterprise-lan id
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
Library ID
PubVis ID
Enterprise-LAN
ID
ISO card ID
Student ID
Email address
Empl ID
UUID
Pseudo ID
Acct login
Departmental
IDs
Person registry 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
Michigan Tech Univ
U Hawaii
Univ of Pittsburgh
Johns Hopkins
Univ of Southern Cal
Univ of Maryland, BC
Tufts Univ
Univ of Memphis
Univ of Tennessee, Memphis
Univ of Michigan
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