internet2 middleware activities progress

Internet2 Middleware Activities Progress

Renee Woodten FrostProject Manager, Internet2 Middleware InitiativeI2 Middleware Liaison, University of Michigan

………………. And an ensemble of hundreds

CIC AIS Directors Spring 2001

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 WisconsinHEPKI-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


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


Early Harvest and Early Adopters

Early harvest in the barn…http://middleware.internet2.edu/best-practices.html

Early adopters aggressively doing deploymentshttp://middleware.internet2.edu/earlyadoptersMichigan Tech, U Maryland BC, Johns Hopkins, etchttp://www.colorado.edu/committees/DirectoryServices/


LDAP Recipe

How to build and operate a directory in higher ed1 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-recipe/


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


eduPerson

A directory objectclass intended to support inter-institutional applicationsFills gaps in traditional directory schemaFor existing attributes, states good practices where knownSpecifies 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


Issues about Upper Class Attributes

eduPerson inherits attributes from person, iNetOrgPersonSome 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.)


New eduPerson Attributes

eduPersonAffiliationeduPersonPrimaryAffiliationeduPersonOrgDNeduPersonOrgUnitDNeduPersonPrincipalNameeduPersonNickname


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


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


eduPersonPrincipalName

userid@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.


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: [email protected]


A Campus Directory Architecture

Metadirectory

Enterprisedirectory

DirDB

Departmentaldirectories

OS directories(MS, Novell, etc)

Borderdirectory

Registries Sourcesystems


A Directory of Directories

An experiment to build a combined directory search serviceTo show the power of coordinationWill highlight the inconsistencies between institutionsTechnical 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 dn’s)

Michael Gettes, Georgetown, is the project manager


DoD Architecture

Inputs to DoDHEInputs: Local Site ViewCentral Deposit ServiceDoD Config DirectoryOperationSearch Operations

• Search Drill Down from a list


Inputs

RemoteSiteDirectoriesRemote

Data Sources

Central DepositSystems (CDS)

Data Filtering & Submit to CDS

LDAPOracleEtc… Search

DoDConfig


Inputs: Local Site View

LocalData Source

CDS

LDAP

GenerateLDIF Data

Submit final LDIF to CDS using authenticated POST via HTTPS.

Filter LDIF according to local policy. Generate

new LDIF for submission.

DODHE


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.


Metadirectories: Metamerge

www.architech.no is now Metamerge

Higher Education Contact for USA• Keith Hazelton, University of Wisconsin – Madison

[email protected]

This product is available free of charge to Higher Ed in USA

Source code will be in escrow. See Keith for further details.

mailto:[email protected]








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


This begs the following …

If you were given both this Metamerge LDIFTransformer and a Perl script that is the basis for the same functionality – each need to be customized for local purposes – which appears more attractive to you?

Answer: from querying various institutions on this question the common response, nearly 100%, is that use of Metamerge is good, interesting and yields other possibilities not likely with just a Perl script. So, the DoDHE will progress assuming Metamerge. If your institution would like to do something different, then you are welcome to do so. Hopefully a common solution will have benefits beyond a custom solution.


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

http://www.dict.org/bin/Dict?Form=Dict3&Database=web1913


Shibboleth

An initiative to analyze and develop mechanisms(architectures, frameworks, protocols and implementations) for inter-institutional web access controlFacilitated by Mace (a committee of leading higher ed IT architects) and Internet2“Authenticate locally, act globally” the Shibboleth shibbolethOriented towards privacy and complements corporate standards effortsOpen solutionhttp://middleware.internet2.edu/shibbolethVendor participation - IBM et al


Isn’t This What PKI Does?

PKI does this and a whole lot more; as a consequence, PKI does very little right nowEnd-to-end PKI fits the Shibboleth model, but other forms of authentication do as wellUses 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 don’t work today (eg client certs).Allows campuses to use other forms of authentication locallyMay actually have benefits over the end-user to target-site direct interactions...


Related Work

Previous DLF workhttp://www.clir.org/diglib/presentations/cnis99/sld001.htm

OASIS Technical Committee (vendor activity, kicked off 1/2001)http://www.oasis-open.org/committees/security/

index.shtmlhttp://lists.oasis-open.org/archives/security-services/

UK - Athens and Sparta projectshttp://www.jisc.ac.uk/pub00/sparta_disc.html

Spain - rediris projecthttp://www.rediris.es/app/papi/index.en.html


Assumptions

“authenticate locally, act globally” the Shibboleth shibbolethLeverage vendor and standards activity wherever possibleDisturb as little of the existing campus infrastructure as possibleWork with common, minimal authorization systems (eg htaccess)Encourage good campus behaviorsLearn through doingCreate a marketplace and reference implementationsWe will not be another dead guppyProtect Personal Privacy!


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


Stage 1 - Addressing Three Scenario’s

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.


Architectural Model

Local AuthenticationLocal 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..)


Target Web

Server

Origin Site Target Site

Browser

Authentication Phase

First Access - Unauthenticated

Authorization Phase

Pass content if user is allowed

Shibboleth ArchitectureConcepts - High Level


Second Access - Authenticated

Target Web

Server


Browser

First Access - Unauthenticated

Web Login Server Redirect User to Local Web Login

Ask to Obtain Entitlements

Pass entitlements for authz decisionPass content if user is allowedAuthentication

AttributeServer

Entitlements

Auth OK

Req Ent

Ent Prompt

Authentication Phase

Authorization Phase

Success!

Shibboleth ArchitectureConcepts (detail)


Target Web

Server


Browser

AttributeServer Shib

htaccessplugin

Club Shib Server (holds

certs and contracts)

Shibboleth ArchitectureConcepts #1 (managing trust)


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


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


Internals of the Shibboleth Model:Functions 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.


Internals of the Shibboleth Model:Services, standards, protocols

Local authentication

service

OASIS XML Standard Inter-realm information exchangeprotocols for authentication

and authorization

Local Shibbolethcontrol point

Web accesscontrolservice

Web SSO

service

Institutional shib keydistribution service Where from

service

Identifierprivacy engine

CredentialFactory

Local attribute server


Shibboleth Components


Descriptions of services

local authentication server - assumed part of the campus environmentweb sso server - typically works with local authn service to provide web single sign-onresource manager proxy, resource manager - may serve as control points for actual web page accessattribute authority - assembles/disassembles/validates signed XML objects using attribute repository and policy tablesattribute 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 serviceattribute mapper - converts user entitlements into local authorization valuesPDP - policy decision points - decide if user attributes meet authorization requirementsSHAR - Shibboleth Attribute Requestor - used by target to request user attributes


Component Relationship Model

ORIGIN TARGET

Policy

Authentication Authority

Attribute Authority

Policy

Policy Decision

Point

Policy

Policy Enforcement

Point

Other Other Other

Authentication Assertion

Authorization Attributes

Authorization Decision

Access OK/ Send Error

Credentials

ASSERTIONS

User Control


Authorization Attributes

Typical Assertions in the Higher Ed Community

• [email protected]• “active member of the community”• “active in course X”• member of group “georgetown.giia• ?

Signed by the institution! (optional in OASIS, required in Shib)


Isn’t This What LDAP Does?

Since this doesn’t exist yet, it can do a lot more than LDAP! (-:

XML is so extensible that this is the last protocol that we’ll ever need! (-:

OK, tell me really…..

• The key here is the CONTROLLED dissemination of attribute information, based on multiple factors.


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


Project Status/Next Steps

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


Middleware Inputs & Outputs

GridsGrids JA-SIG &JA-SIG &uPortaluPortalOKIOKI Inter-realmInter-realm

calendaringcalendaring

Shibboleth, eduPerson, Affiliated Dirs, etc.Shibboleth, eduPerson, Affiliated Dirs, etc.

EnterpriseEnterpriseDirectoryDirectory

EnterpriseEnterpriseAuthenticationAuthentication

LegacyLegacySystemsSystems

CampusCampusweb ssoweb sso

futuresfutures

EnterpriseEnterpriseAuthZAuthZ

LicensedLicensedResourcesResources

EmbeddedEmbeddedApp SecurityApp Security

Shibboleth, eduPerson, and everything else


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


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


HEPKI-PAG

David Wasley, UCOP, prime mover

Draft certificate policy for a campus

HEBCA certificate policy

FERPA

State Legislatures

Gartner Group Decision Maker software


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


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.


The applications view of medical upperware

Server (in this scenario)

DoD Clinical System

Client (in this scenario)

VA Clinical System

Request lab data, This Soldier, this time frame

Who’s asking? What role? What is need to know?

ResourceAccess

Decision(RAD)

Who is this person? Who knows this person?

PersonIdentification

Service (PIDS)

Where is lab info on this person?

Health Information

Locator Service (HILS)

Convert to server’s terms

Terminology Query Service

(TQS)outbound

Clinical Observation

Access Service(COAS)

Requestobservation


The enterprise architect view of medical middleware

Person registry

Enterprise directory

Appdir

BorderDirectory

LAN dir

InstitutionalStudentFinancialPersonnelSystems

MedicalAdministrativeSystems

HospitalAdministrativeSystems

Peer institutions

PKI

AuthenticationServices

FederalState

Gov’ts

Corporatecollaborators

Internet

Research Systems

AuthorizationServices


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


K-12

The killer app may be a spreadsheet and resource discovery

Directories to locate information

Directories to store experiments

Technology isn’t enough


More information

Early Harvest / Early Adopters: http://middleware.internet2.edu/earlyadopters/Mace: middleware.internet2.eduLDAP Recipe: http://www.georgetown.edu/giia/internet2/ldap- recipe/EduPerson: www.educause.edu/edupersonDirectory of Directories: middleware.internet2.edu/dodheShibboleth: middleware.internet2.edu/shibbolethHEPKI-TAG: www.educause.edu/hepkiHEPKI-PAG: www.educause.edu/hepkiMedical Middleware: web site to followOpportunities: video, the GRID, K-12

internet2 middleware activities progress

Documents

core middleware

new attributes

early adoptersearly

tbsp schema design

higher edmembership

higher ed1

ldap recipehow

controlled vocabulary