Current Activities in Middleware Ken Klingenstein, Project Director, Internet2 Middleware Initiative...
-
Upload
vernon-chapman -
Category
Documents
-
view
214 -
download
0
Transcript of Current Activities in Middleware Ken Klingenstein, Project Director, Internet2 Middleware Initiative...
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