Internet2 Progress Report Middleware Experiments

1
Internet2 Progress ReportMiddleware Experiments

• Renee Woodten Frost
• Project Manager, Internet2 Middleware Initiative
• I2 Middleware Liaison, University of Michigan
• . And an ensemble of hundreds

2
Topics

• Internet2 Overview
• Middleware Overview
• Directories
• LDAP Recipe
• EduPerson
• Directory of Directories for Higher Ed
• Shibboleth
• PKI
• Medical Middleware
• New Opportunities Video, the Grid, K-12

3
Internet2 Overview

• Mission
• Develop and deploy advanced network applications
  and technologies, accelerating the creation of
  tomorrows Internet.
• Goals
• Enable new generation of applications
• Re-create leading edge RE network capability
• Transfer technology and experience to the global
  production Internet

4
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 identitys
  characteristics are kept
• Authorization - what an identity is permitted to
  do
• Security - ie, PKI - emerging tools for security
  services

5
Activities

• Mace - RL Bob Morgan (Washington)
• Early Harvest / Early Adopters - Renee Frost
  (Michigan)
• LDAP Recipe - Michael Gettes (Georgetown)
• EduPerson - Keith Hazelton (Wisconsin)
• Directory of Directories - Michael Gettes
  (Georgetown)
• Metadirectories - Keith Hazelton (Wisconsin)
• Shibboleth - Steven Carmody (Brown)
• PKI Labs - Dartmouth and Wisconsin
• HEPKI-TAG and PAG - Jim Jokl (Virginia) and Ken
  Klingenstein (Colorado)
• HEBCA - Mark Luker (EDUCAUSE)
• Medical Middleware - Rob Carter (Duke), Jack
  Buchanan (UT, Memphis)
• Opportunities - video, the GRID, K-12

6
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)
• Jim Jokl (Virginia)
• Mark Poepping (CMU)
• David Wasley (U California)
• Von Welch (NCSA)

7
Early Harvest and Early Adopters

• Early harvest in the barn
• http//middleware.internet2.edu/best-practices.ht
  ml
• Early adopters aggressively doing deployments
• http//middleware.internet2.edu/earlyadopters
• Michigan Tech, U Maryland BC, Johns Hopkins, etc
• http//www.colorado.edu/committees/DirectoryServi
  ces/

8
LDAP Recipe

• How to build and operate a directory in higher ed
• 1 Tsp. DIT planning 1 Tbsp Schema design 3 oz.
  configuration 1000 lbs of data
• Good details, such as tradeoffs/recommendations
  on indexing, how and when to replicate, etc.
• http//www.georgetown.edu/giia/internet2/ldap-reci
  pe/

9
LDAP Recipe Contents

• Directory Information TreeSchema
  DesignDirectory of Directories for Higher
  Education (DoDHE) expectationsSchema Design
  (continued)Schema How to upgrade it?Password
  ManagementBindingseduPerson attribute
  discussionsAccess ControlReplicationName
  PopulationLDAP filter config file for white
  pagestelephoneNumber formattingCHANGELOG

10
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

11
Issues about Upper Class Attributes

• eduPerson inherits attributes from person,
  iNetOrgPerson
• Some of those attributes need conventions about
  controlled vocabulary (e.g. telephones)
• Some of those attributes need ambiguity resolved
  via a consistent interpretation (e.g. email
  address)
• Some of the attributes need standards around
  indexing and search (e.g. compound surnames)
• Many of those attributes need access control and
  privacy decisions (e.g jpeg photo, email address,
  etc.)

12
New eduPerson Attributes

• eduPersonAffiliation
• eduPersonPrimaryAffiliation
• eduPersonOrgDN
• eduPersonOrgUnitDN
• eduPersonPrincipalName
• eduPersonNickname

13
eduPersonAffiliation

• Multi-valued list of relationships an individual
  has with institution
• Controlled vocabulary includes faculty, staff,
  student, alum, member, affiliate, employee
• Applications that use DoD, white pages

14
eduPersonPrimaryAffiliation

• Single-valued attribute that would be the status
  put on a name badge at a conference
• Controlled vocabulary includes faculty, staff,
  student, alum, member, affiliate, employee
• Applications that use DoD, white pages

15
eduPersonPrincipalName

• userid_at_securitydomain
• EPPN may look like an email address but it is
  used by different systems.
• One must be able to authenticate against the EPPN
  
• used in inter-realm authentication such as
  Shibboleth
• In some situations, it can be used for access
  control lists if used, a site should understand
  the reassignment policy.

16
Next Steps

• eduPerson 1.0 done, along with FAQ and letter to
  implementers
• Ties closely to LDAP recipe
• Version 2.0 to include attributes for
  videoconferencing, additional collaboration
  factors, links to Grids, portals, etc.
• Check with web site for additional changes
• Participate mace-dir_at_internet2.edu

17
A Campus Directory Architecture
Border directory
Metadirectory
Enterprise directory
OS directories (MS, Novell, etc)
Departmental directories
Dir DB
Registries
Source systems
18
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 interfaces issues - searching large name
  spaces with limits by substring, location,
  affiliation, etc...
• Two different experimental regimes to be tested
• centralized indexing and repository with
  referrals
• large-scale parallel searches with heuristics to
  constrain search space
• SUN donation of server and iPlanet license
  (6,000,000 dns)
• Michael Gettes, Georgetown, is the project manager

19
DoD Architecture

• Inputs to DoDHE
• Inputs Local Site View
• Central Deposit Service
• DoD Config Directory
• Operation
• Search Operations
• Search Drill Down from a list

20
Inputs
Remote Site Directories
Remote Data Sources
LDAP Oracle Etc
Search
Data Filtering Submit to CDS
DoD Config
Central Deposit Systems (CDS)
21
Inputs Local Site View
Submit final LDIF to CDS using authenticated POST
via HTTPS.
Local Data Source
LDAP
Filter LDIF according to local policy. Generate
new LDIF for submission.
DODHE
Generate LDIF Data
22
Inputs Why this way?

• Standardized input is LDIF
• Could be XML but few products generate XML now
  (01/2001)
• Could use Metamerge Integrator as filter and
  submission mechanism
• Site always submits full dataset. No worry of
  reconciling. Easier site participation in the
  DoDHE service.
• CDS handles reconciliation and controls data
  processing. Can provide feedback.

23
Metadirectories Metamerge

• www.architech.no is now Metamerge
• Higher Education Contact for USA
• Keith Hazelton, University of Wisconsin Madison
• hazelton_at_doit.wisc.edu
• This product is available free of charge to
  Higher Ed in USA
• Source code will be in escrow. See Keith for
  further details.

24
Metamerge Features

• GUI development environment
• NOT a Meta-Directory, but a tool to build same
  functionality
• Various Languages JavaScript, Java, Perl, Rexx,
  etc
• Various Parsers XML, LDIF, CSV, Script
  Interface, etc
• for input and output
• Various Connectors COMport, Files, HTTP,
  HTTPserver, FTP, LDAP, JDBC, Oracle and more
• The product is ALL Java

25
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)

26
Shibboleth

• An initiative to analyze develop mechanisms
  (architectures, frameworks, protocols
  implementations) for inter-institutional web
  access control
• Facilitated by Mace (a committee of leading
  higher ed IT architects) and Internet2
• Authenticate locally, act globally is the
  Shibboleth shibboleth
• Oriented towards privacy and complements
  corporate standards efforts
• Open solution
• http//middleware.internet2.edu/shibboleth
• Vendor participation - IBM et al

27
Isnt This What PKI Does?

• PKI does this and a whole lot more as a
  consequence, PKI does very little right now
• End-to-end PKI fits the Shibboleth model, but
  other forms of authentication do as well
• Uses a lightweight certificate approach for
  inter-institutional communications - uses the
  parts of PKI that work today (server side certs)
  and avoids the parts of PKI that dont work today
  (eg client certs).
• Allows campuses to use other forms of
  authentication locally
• May actually have benefits over the end-user to
  target-site direct interactions...

28
Related Work

• Previous DLF work
• http//www.clir.org/diglib/presentations/cnis99/s
  ld001.htm
• OASIS Technical Committee (vendor activity,
  kicked off 1/2001)
• http//www.oasis-open.org/committees/security/ind
  ex.shtml
• http//lists.oasis-open.org/archives/security-ser
  vices/
• UK - Athens and Sparta projects
• http//www.jisc.ac.uk/pub00/sparta_disc.html
• Spain - rediris project
• http//www.rediris.es/app/papi/index.en.html

29
Assumptions

• authenticate locally, act globally the
  Shibboleth shibboleth
• Leverage vendor and standards activity wherever
  possible
• Disturb as little of the existing campus
  infrastructure as possible
• Work with common, minimal authorization systems
  (eg htaccess)
• Encourage good campus behaviors
• Learn through doing
• Create a marketplace and reference
  implementations
• We will not be another dead guppy
• Protect Personal Privacy!

30
Development Process

• Scenarios leading to requirements
• Establish model architectures for common services
  and scenario-specific services
• Develop service and protocol requirements
• Identify service options/begin protocol
  development
• Produce open implementations of missing service
  components provide external services as needed

31
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.

32
Architectural Model

• Local Authentication
• Local Entity Willing to Create and Sign
  Entitlement
• Set of assertions about the user (Attribute/value
  pairs)
• User has control over disclosure
• Identity optional
• active member of community, Associated with
  Course XYZ
• Target responsible for Authorization
• Rules engine
• Matches contents of entitlements against ruleset
  associated with target object
• Cross Domain Trust
• Previously created between origin and target
• Perhaps there is a contract (information
  providers..)

33
Shibboleth ArchitectureConcepts - High Level
Browser
Pass content if user is allowed
Target Web Server
Authorization Phase
Authentication Phase
First Access - Unauthenticated
Origin Site
Target Site
34
Shibboleth ArchitectureConcepts (detail)
Target Web Server
Browser
Authentication Phase
Authorization Phase
Success!
Entitlements
Attribute Server
Ent Prompt
Req Ent
Second Access - Authenticated
Auth OK
Pass entitlements for authz decision
Web Login Server
Redirect User to Local Web Login
Pass content if user is allowed
Authentication
Ask to Obtain Entitlements
First Access - Unauthenticated
Target Site
Origin Site
35
Shibboleth ArchitectureConcepts 1 (managing
trust)
Club Shib Server (holds certs and contracts)
Attribute Server
Shib htaccess plugin
Target Web Server
Browser
Origin Site
Target Site
36
Internals of the Shibboleth ModelFunctions and
Standards

• There are component services that are assumed to
  exist already on campuses
• There are new functional services that must be
  implemented
• There are new protocols that must be developed
• There are data and metadata definitions that must
  be standardized.

37
Internals of the Shibboleth ModelServices,
standards, protocols
Institutional shib key distribution service
Identifier privacy engine
Where from service
Web access control service
Inter-realm information exchange protocols for
authentication and authorization
OASIS XML Standard
Credential Factory
Local authentication service
Web SSO service
Local Shibboleth control point
Local attribute server
38
Descriptions of services

• local authentication server - assumed part of the
  campus environment
• web sso server - typically works with local authn
  service to provide web single sign-on
• resource manager proxy, resource manager - may
  serve as control points for actual web page
  access
• attribute authority - assembles/disassembles/valid
  ates signed XML objects using attribute
  repository and policy tables
• attribute repository - an LDAP directory, or
  roles database or.
• Where are you from service - one possible way to
  direct external users to their own local authn
  service
• attribute mapper - converts user entitlements
  into local authorization values
• PDP - policy decision points - decide if user
  attributes meet authorization requirements
• SHAR - Shibboleth Attribute Requestor - used by
  target to request user attributes

39
Component Relationship Model
TARGET
ORIGIN
40
Campus and Resource Requirements

• To Participate in Shibboleth, a site must have
• Campus-wide authentication service
• Campus-wide identifier space (EPPN)
• Implementation of EduPerson objectclass
• Ability to generate attributes (eg active member
  of the community)

41
Authorization Attributes

• Typical Assertions in the Higher Ed Community
• EPPNgettes_at_georgetown.edu
• active member of the community
• active in course X
• member of group georgetown.giia
• ?
• Signed by the institution! (optional in OASIS,
  required in Shib)

42
Charge -- OASIS Security Services Technical
Committee

• Standardize
• an XML format for "assertions (authentication,
  authorization, authorization decision, access
  yes/no)
• (maybe) a (stateless ?) request/response protocol
  for obtaining assertions
• transport bindings for this protocol to HTTP,
  S/MIME, RMI, etc.
• This will be accompanied by requirements/scenarios
  , compliance info, security considerations, etc
• Out of Scope
• How authentication is done
• Defining specific attributes (eg member of
  community)
• Establishing trust between origin and target
• Note..
• Inter-product, not explicitly inter-domain

43
Issues

• Personal Privacy (reasonable expectation, laws)
• Relation to local weblogin (Single Signon)
• Portals
• Use of Shibboleth framework by services beyond
  the web
• Grid resources and users

44
Project Status/Next Steps

• Requirements and Scenarios document nearly
  finished
• IBM Mace-Shibboleth refining architecture
  evaluating issues
• IBM intends to develop an Apache web module
• Internet2 intends to develop supporting materials
  (documentation, installation, etc) and web tools
  (for htaccess construction, filter access
  control, remote resource attribute discovery).
• Technical design complete - May, 2001
• Coding of a prototype begins June 1
• Pilot sites start-up - Aug, 2001
• Public demo of the prototype by the pilots -
  Internet2 Fall Member Meeting 2001

45
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
46
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

47
HEPKI-TAG

• Chaired by Jim Jokl, Virginia
• Certificate profiles
• survey of existing uses
• development of standard presentation
• identity cert standard recommendation
• Mobility options IETF SACRED scenarios
• Public domain software alternatives

48
HEPKI-PAG

• David Wasley, UCOP, prime mover
• Draft certificate policy for a campus
• HEBCA certificate policy
• FERPA
• State Legislatures
• Gartner Group Decision Maker software

49
Medical Middleware

• 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

50
The complex challenges of academic medical
middleware

• Intra-realm issues - multiple vendors,
  proprietary systems, evolving regulations
• Enterprise issues - security, directories,
  authorization balance of institutional and
  medical enterprises
• Inter-realm issues - standards, gateways, common
  operational processes and policies, performance
• Multiple communities of interest - institutional,
  medical center, affiliated hospitals, state and
  federal regulatory and certification
  organizations, insurance companies, medical
  researchers, etc.

51
The applications view of medical upperware
52
The enterprise architect view of medical
middleware
Internet
Research Systems
Hospital Administrative Systems
Medical Administrative Systems
App dir
LAN dir
Border Directory
Peer institutions
Institutional Student Financial Personnel Systems
Enterprise directory
Corporate collaborators
PKI
Federal State Govts
Person registry
Authorization Services
Authentication Services
53
Video

• A variety of tools - vic/vat, H.323, MPEG 2,
  HDTV
• Point-to-point and MCU options
• H.323 desktop video within reach at physical
  layer
• Lacks identifiers and authentication
• EPPN and Shibboleth-type flow could address

54
K-12

• The killer app may be a spreadsheet and resource
  discovery
• Directories to locate information
• Directories to store experiments
• Technology isnt enough

55
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
• Medical Middleware web site to follow
• Opportunities video, the GRID, K-12