Upload
ursa
View
29
Download
1
Embed Size (px)
DESCRIPTION
Current Activities in Middleware. Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder. Application requirements - Digital libraries, Grids, IMS, Portals, etc... Early Harvest best practices Early Adopters - PowerPoint PPT Presentation
Citation preview
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/[email protected] workGlobus.org