Internet2 Middleware Activities Progress

1
Internet2 Middleware Activities Progress
2
Acknowledgments

• MACE and the working groups
• NSF catalytic grant and meeting
• Early Adopters
• Higher Education partners - campuses, EDUCAUSE,
  CREN, AACRAO, SURA, NACUA, etc.
• Corporate partners - IBM, ATT, Sun, Accord,
  Metamerge, et al.
• Government partners - including NSF and the fPKI
  TWG

3
Activites

• Integration
• MACE RLBobMorgan (Washington)
• Early Harvest / Early Adopters Renee Frost
  (Michigan)
• Shibboleth - Steven Carmody (Brown)
• Vid Mid - Ken Klingenstein (Colorado)
• VC- Egon Verharen (SURFnet)
• VoD- Mairead Martin (Tennessee)
• NSF Middleware Initiative Internet2, EDUCAUSE,
  SURA and The GRIDs Center
• Medical Middleware - Rob Carter (Duke), Jack
  Buchanan (UT Health Science Ctr)

• Core
• MACE- Dir Keith Hazelton(Wisconsin)
• Groups- Tom Barton (Memphis)
• Metadirectories - Keith Hazelton (Wisconsin)
• Directory of Directories for Higher Ed - Michael
  Gettes (Georgetown)
• EduPerson and EduOrg - Keith Hazelton (Wisconsin)
• LDAP Recipe - Michael Gettes (Georgetown)
• HEPKI-TAG and PAG - Jim Jokl (Virginia) and Ken
  Klingenstein (Colorado)
• HEBCA - Mark Luker (EDUCAUSE)
• PKI Labs - Dartmouth and Wisconsin

4
MACE (Middleware Architecture Committee for
Education)

• Purpose - to provide advice, create experiments,
  foster standards, etc. on key technical issues
  for core middleware within higher education
• Creates working groups in major areas, including
  directories, interrealm authentication, PKI,
  medical issues, etc.
• Works via conference calls, emails, occasional
  serendipitous in-person meetings...

• US Members
• Bob Morgan (UW) Chair Scott Cantor (Ohio State)
  Steven Carmody (Brown)
• Keith Hazelton (Wisconsin) Paul Hill (MIT)
  Michael Gettes (Georgetown)
• Jim Jokl (Virginia) Mark Poepping (CMU) Bruce
  Vincent (Stanford)
• David Wasley (California) Von Welch (Grid)
• European members
• Brian Gilmore (Edinburgh) Ton Verschuren
  (Netherlands)

5
National Science Foundation

• Catalytic grant in Fall 99 started the organized
  efforts, with Early Harvest and Early Adopters
• NSF Middleware Initiative - three year
  cooperative agreement, begun 9/1/01, with
  Internet2/EDUCAUSE/SURA and the GRIDs Center, to
  develop and deploy a national middleware
  infrastructure for science, research and higher
  education
• Work products are community standards, best
  practices, schema and object classes, reference
  implementations, open source services, corporate
  relations
• Work areas are identifiers, directories,
  authentication, authorization, GRIDs, PKI, video

6
Early Harvest

• NSF funded workshop in Fall 99 and subsequent
  activities
• Defined the territory and established a work plan
• Best practices in identifiers, authentication,
  and directories (http//middleware.internet2.edu/i
  nternet2-mi-best-practices-00.html)
• http//middleware.internet2.edu/earlyharvest/

7
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
• Profiles and plans are on Internet2 middleware
  site
• http//middleware.internet2.edu/earlyadopters
  /
• Participants Dartmouth, Hawaii, Johns Hopkins,
  Maryland-Baltimore County, Memphis, Michigan
  Tech, Michigan, Pittsburgh, Tennessee Health
  Science Center, Tufts, USC

8
What is Middleware?

• specialized networked services that are shared by
  applications and users
• a set of core software components that permit
  scaling of applications and networks
• tools that take the complexity out of application
  integration
• a second layer of the IT infrastructure, sitting
  above the network
• a land where technology meets policy
• the intersection of what networks designers and
  applications developers each do not want to do

9
A Map of Middleware
10
Core Middleware

• Identity - unique markers of who you (person,
  machine, service, group) are
• Authentication - how you prove or establish that
  you are that identity
• Directories - where an identitys basic
  characteristics are kept
• Authorization - what an identity is permitted to
  do
• PKI - emerging tools for security services

11
The Major Projects

• eduPerson and eduOrg (mace-dir)
• the Directory of Directories for Higher Education
  (DoDHE)
• Shibboleth (mace-shibboleth) and Webiso
  (mace-webiso)
• Directories
• metadirectories
• groups
• affiliated directories
• HEBCA and PKI-Light (HEPKI-PAG and HEPKI-TAG)
• PKI Labs at Dartmouth and Wisconsin
• Videoconferencing and video on demand (vidmid)
• OKI, JA-SIG and the Grids

12
eduPerson

• A directory objectclass intended to support
  inter-institutional applications
• Fills gaps in traditional directory schema
• For existing attributes, states good practices
  where known
• Specifies several new attributes and controlled
  vocabulary to use as values.
• Provides suggestions on how to assign values, but
  it is up to the institution to choose.
• Version 1.0 now done one or two revisions
  anticipated

13
eduPerson 1.0

• parent objectclassinetOrgPerson
• includes
• affiliation (multi-valued)
• primary affiliation (faculty/student/staff)
• orgUnitDN (string)
• nickname (string)
• ePPN (identifier, user_at_securitydomain)
• version 1.5 and beyond will contain other shared
  attributes

14
A Directory of Directories

• an experiment to build a combined directory
  search service
• to show the power of coordination
• will highlight the inconsistencies between
  institutions
• technical investigation of load and scaling
  issues, centralized and decentralized approaches
• human interface issues - searching large name
  spaces with limits by substring, location,
  affiliation, etc...
• to suggest the service to follow
• Sun donation of server and 6 million DNs
• http//dodhe.internet2.edu/dodhe/

15
Shibboleth

• A word which was made the criterion by which to
  distinguish the Ephraimites from the Gileadites.
  The Ephraimites, not being able to pronounce sh,
  called the word sibboleth. See --Judges xii.
• Hence, the criterion, test, or watchword of a
  party a party cry or pet phrase.
• - Webster's Revised Unabridged Dictionary
  (1913)

16
Shibboleth

• inter-institutional web authentication and basic
  authorization
• authenticate locally, act globally - the
  Shibboleth shibboleth
• emphasizes privacy through progressive disclosure
  of attributes
• linked to commercial standards development in XML
  through OASIS
• scenarios and architecture done coding has
  commenced with alpha code due in January, 2002 to
  pilot sites
• coding and design teams feature IBM/Tivoli, CMU,
  and the Ohio State University
• strong partnership with IBM to develop and deploy
• http//middleware.internet2.edu/shibboleth/

17
Stage 1 - Addressing Three Scenarios

• Member of campus community accessing licensed
  resource
• Anonymity required
• Member of a course accessing remotely controlled
  resource
• Anonymity required
• Member of a workgroup accessing controlled
  resources
• Controlled by unique identifiers (e.g. name)
• Taken individually, each of these situations can
  be solved in a variety of straightforward ways.
• Taken together, they present the challenge of
  meeting the user's reasonable expectations for
  protection of their personal privacy.

18
Shibboleth ArchitectureConcepts - High Level
Browser
Pass content if user is allowed
Target Web Server
Authorization Phase
Authentication Phase
First Access - Unauthenticated
Target Site
Origin Site
19
Shibboleth, eduPerson, and everything else
Middleware Inputs Outputs
Licensed Resources
Embedded App Security
Grids
JA-SIG uPortal
OKI
Inter-realm calendaring
futures
Shibboleth, eduPerson, Affiliated Dirs, etc.
Enterprise authZ
Enterprise Directory
Enterprise Authentication
Legacy Systems
Campus web SSO
20
Project Status

• Architecture definition finished (v0.9)
• Design/Programming now Underway
• Team membership drawn from IBM/Tivoli, CMU, Ohio
  State
• First Face-to-Face meeting on Sept 27, 28 at CMU
• First Set of Pilot Sites Selected
• Chosen to test all 3 scenarios
• UK participation
• Timeline for programming
• Stage I alpha code Feb 2002
• Stage II beta code June 2002
• Stage III release summer 2002

21
A Campus Directory Architecture
Border directory
Metadirectory
Enterprise directory
OS directories (MS, Novell, etc)
Departmental directories
Dir DB
Registries
Source systems
22
Metadirectories

• The critical functions to glue together what
  inevitably turns out to be a number of campus,
  departmental and application-oriented directory
  services
• Typically a coordinated set of services that
  watches updates to specific directories or from
  legacy data feeds and spreads those updates to
  other directories
• Performs several subfunctions
• an identity registry or crosswalk to relate
  entries in different directories
• a set of connectors that take changes from one
  source and convert them for dissemination to
  other sources
• Basic implementation from Metamerge is free to
  higher ed

23
Directories Group Management

• Best practices in the use of core middleware to
  meet the authorization and messaging needs of
  applications
• Initial foci are
• the conduct of a survey of several organizations'
  practices in this area and
• investigations into meaningful definitions of,
  and productive ways of representing and operating
  on, "groups", "affiliations", "roles", and
  "correlations".
• Groups Practices Survey
• http//middleware.internet2.edu/dir/groups/

24
PKI A few observations

• Think of it as wall jack connectivity, except
  its connectivity for individuals, not for
  machines, and theres no wall or jackbut it is
  that ubiquitous and important
• Does it need to be a single infrastructure? What
  are the costs of multiple solutions? Subnets and
  ITPs...
• Options breed complexity managing complexity is
  essential
• PKI can do so much that right now it does very
  little

25
A few more...

• IP connectivity was a field of dreams. We built
  it and then the applications came. Unfortunately,
  here the applications have arrived before the
  infrastructure, making its development much
  harder.
• No one seems to be working on the solutions for
  the agora.
• A general-purpose PKI seems like a difficult
  task, but instituting a PKI Light as a first step
  may not have enough paybacks.

26
The general state of PKI

• There are campus and corporate successes
• Corporations use internally for VPN, some
  authentication, signed email (with homogeneous
  client base)
• MIT, UT medical, soon VA, UCOP
• Key is limited application use, lightweight
  policy approaches
• There is very limited interrealm, community of
  interest or general interoperable work going on
• Federal efforts
• HealthKey
• Higher Ed
• Some European niches

27
The Four Planes of PKI

• on the road to general purpose interrealm PKI
• the planes represent different levels of
  simplification from the dream of a full
  interrealm, intercommunity multipurpose PKI
• simplifications in policies, technologies,
  applications, scope
• each plane provides experience and value

28
The Four Planes are

• Full interrealm PKI - multipurpose, spanning
  broad and multiple communities, bridges to unite
  hierarchies, unfathomed directory issues
• Simple interrealm PKI - multipurpose within a
  community, operating under standard policies and
  structured hierarchical directory services
• PKI-Light - containing all the key components of
  a PKI, but many in simplified form may be for a
  limited set of applications may be extended
  within selected communities
• PKI-Ultralight - easiest to construct and useful
  conveyance ignores parts of PKI and not for use
  external to the institution learn how to fly,
  but not a plane...

29
D. Wasleys PKI Puzzle
30
Uses for PKI and Certificates

• authentication and pseudo-authentication
• signing docs
• encrypting docs and mail
• non-repudiation
• secure channels across a network
• authorization and attributes
• secure multicast
• and more...

31
PKI Components

• X.509 v3 certs - profiles and uses
• Validation - Certificate Revocation Lists, OCSP,
  path construction
• Cert management - generating certs, using keys,
  archiving and escrow, mobility, etc.
• Directories - to store certs, and public keys and
  maybe private keys
• Trust models and I/A
• Cert-enabled apps

32
Directories

• to store certs
• to store CRL
• to store private keys, for the time being
• to store attributes
• implement with border directories, or ACLs within
  the enterprise directory, or proprietary
  directories

33
Certificate Policies (CP) and Practices
Statements (CPS)

• Policies legal responsibilities and liabilities
  (indemnification issues)
• Operations of certificate management systems
• Will hopefully be somewhat uniform across the
  community
• Assurance levels - varies according to I/A
  processes and other operational factors
• Practices - site-specific details of operational
  compliance with a cert policy
• A Policy Management Authority (PMA) determines if
  a CPS is adequate for a given CP.

34
Inter-organizational trust model components

• verifying sender-receiver assurance by finding a
  common trusted entity
• must traverse perhaps branching paths to
  establish trust paths
• must then use CRLs etc. to validate assurance
• if policies are in cert payloads, then validation
  can be quite complex
• delegation makes things even harder
• Hierarchies vs. Bridges
• a philosophy and an implementation issue
• the concerns are transitivity and delegation
• hierarchies assert a common trust model
• bridges pairwise agree on trust models and policy
  mappings

35
VidMid

• Middleware for video
• Videoconferencing
• authenticated, identified video clients - work
  with commercial clients to use the underlying
  middleware plumbing
• H.323, VRVS, and new SIP-oriented clients
• Video on demand
• access controls for video resources
• schema for meta information
• Works closely with ViDe (www.vide.org)
• http//middleware.internet2.edu/video/
• aggressive time frames

36
Mace-Med

• Unique requirements - HIPAA, disparate
  relationships, extended community, etc.
• Unique demands - 7x24, visibility
• PKI seen as a key tool
• Mace-Med recently formed to explore the issues

37
HEPKI (www.educause.edu/hepki/)

• HEPKI - Technical Activities Group (TAG)
• universities actively working technical issues
• topics include Kerberos-PKI integration, public
  domain CA, profiles
• regular conference calls, email archives
• HEPKI - Policy Activities Group (PAG)
• universities actively trying to deploy PKI
• topics include certificate policies, RFP sharing,
  interactions with state governments
• regular conference calls, email archives

38
Internet2 PKI Labs

• At Dartmouth and Wisconsin in computer science
  departments and IT organizations
• Doing the deep research - two to five years out
• Policy languages, path construction, attribute
  certificates, etc.
• National Advisory Board of leading academic and
  corporate PKI experts provides direction
• Catalyzed by startup funding from ATT

39
OKI, JA-SIG and Grids

• OKI
• major open learning management system being
  developed by MIT, Stanford, and North Carolina
  State, funded by the Mellon Foundation reference
  architecture and open source implementation
• http//web.mit.edu/oki/intro.html
• JA-SIG
• uPortal is a major portal architecture and
  implementation being developed by a number of
  schools with funding from the Mellon Foundation
  also hopes to share administrative Java applets
• http//www.ja-sig.org/ and http//mis105.mis.udel
  .edu/ja-sig/uportal/index.html
• GRIDS Center
• expanding use of Grids will reach to many
  campuses
• integration efforts underway
• http//www.globus.org and http//www.gridforum.org

40
NSF Middleware Initiative (NMI)

• NSF award for integrators to
• Internet2, EDUCAUSE, and SURA
• The GRIDs Center (NCSA, UCSD, University of
  Chicago, USC/ ISI, and University of Wisconsin)
• Build on the successes of the Internet2/MACE
  initiative and the Globus Project
• Three year cooperative agreement effective 9/1/01
• To develop and deploy a national middleware
  infrastructure for science, research and higher
  education
• Separate awards to academic pure research
  components

41
The Grid

• a model for a distributed computing environment,
  addressing diverse computational resources,
  distributed databases, network bandwidth, object
  brokering, security, etc.
• Globus (www.globus.org) is the software that
  implements most of these components Legion is
  another such software environment
• Needs to integrate with campus infrastructure
• Gridforum (www.gridforum.org) umbrella activity
  of agencies and academics
• Look for grids to occur locally and nationally,
  in physics, earthquake engineering, etc.

42
NMI The Problem to Solve

• To allow scientists and engineers the ability to
  transparently use and share distributed
  resources, such as computers, data, and
  instruments
• To develop effective collaboration and
  communications tools such as Grid technologies,
  desktop video, and other advanced services to
  expedite research and education
• To develop a working architecture and approach
  which can be extended to Internet users around
  the world
• Middleware is the stuff that makes transparently
  use happen, providing consistency, security,
  privacy and capability

43
NMI

• Work areas
• Identifiers
• Directories
• Authentication
• Authorization
• GRIDs
• PKI
• Video

• Work products
• Community standards
• Best practices
• Schema and object classes
• Reference implementations
• Open source services
• Corporate relations

44
More information

• Early Harvest / Early Adopters
  http//middleware.internet2.edu/earlyadopters/
• Mace middleware.internet2.edu
• LDAP Recipe http//www.georgetown.edu/giia/inter
  net2/ldap- recipe/
• EduPerson www.educause.edu/eduperson
• Directory of Directories middleware.internet2.e
  du/dodhe
• Shibboleth middleware.internet2.edu/shibboleth
  
• HEPKI-TAG www.educause.edu/hepki
• HEPKI-PAG www.educause.edu/hepki
• Video http//middleware.internet2.edu/video/