Transcript Document 7159591

Middleware Tutorial and Use
Renee Woodten Frost
Project Manager, Internet2 Middleware Initiative
Internet2 Middleware Liaison, University of Michigan
ARKNet 2001
28 March 2001
Topics
Acknowledgements
The larger picture
Core middleware: the basic technologies
•
•
•
•
•
Identifiers
Authentication
Directories
Authorization
PKI
The major projects
• EduPerson, LDAP Recipe, the Directory of Directories, Shibboleth,
HEPKI
What to do and where to watch?
ARKNet 2001
Acknowledgements
MACE and the working groups
Early Harvest - NSF catalytic grant and meeting
Early Adopters
Higher Ed partners - campuses, EDUCAUSE, CREN,
AACRAO, NACUA, etc
Corporate partners - IBM, ATT, SUN, et al...
Government partners - including NSF and the fPKI TWG
ARKNet 2001
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 (Grid)
Creates working groups in major areas, including directories,
inter-realm authentication, PKI, medical issues, video, etc.
Works via conference calls, emails, occasional serendipitous inperson meetings...
ARKNet 2001
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/best-practices.html)
http://middleware.internet2.edu/earlyharvest/
ARKNet 2001
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 I2 middleware site.
ARKNet 2001
Early Adopter Participants
Dartmouth
Michigan Tech Univ
Univ of Hawaii
Univ of Pittsburgh
Johns Hopkins Univ
Univ of Southern California
Univ of Maryland, Baltimore
County
Tufts Univ
Univ of Memphis
Univ of Tennessee Health
Science Center, Memphis
Univ of Michigan
ARKNet 2001
Partnerships
EDUCAUSE
CREN
Grids, JA-SIG, OKI
Campuses
Higher Ed professional associations - AACRAO, NACUA,
CUMREC, etc.
Increasing international interactions
Corporate - IBM, SUN, ATT, etc.
ARKNet 2001
Remedial IT architecture
The proliferation of customizable applications requires a
centralization of “customizations”
The increase in power and complexity of the network requires
access to user profiles
Electronic personal security services is now an impediment to
the next-generation computing grids
Inter-institutional applications require interoperational
deployments of institutional directories and authentication
ARKNet 2001
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
Sits above the network as the second layer of the IT
infrastructure
A land where technology meets policy
The intersection of what networks designers and applications
developers each do not want to do
ARKNet 2001
Specifically,
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. relies on campusbased services and inter-institutional standards
Instructional Management Systems (IMS) needs
authentication and directories
Next-generation portals want common authentication and
storage
Academic collaboration requires restricted sharing of materials
between institutions
What I1 did with communication, I2 may do with collaboration
ARKNet 2001
A Map of Middlewareland
Academic
Computing
Upperware
Research
Oriented
Upperware
Business
Upperware
Core middleware
Network-layer middleware
ARKNet 2001
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.
ARKNet 2001
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 identity’s basic characteristics are kept
Authorization - what an identity is permitted to do
PKI - emerging tools for security services
ARKNet 2001
What is the nature of the work?
Technological
•
•
•
•
Establish campus-wide services: name space, authentication
Build an enterprise directory service
Populate the directory from source systems
Enable applications to use the directory
Policies and Politics
• Clarify relationships between individuals and institution
• Determine who manages, who can update and who can see
common data
• Structure information access and use rules between departments
and central administrative units
• Reconcile business rules and practices
ARKNet 2001
What are the benefits to the
institution?
Economies for central IT - reduced account management, better
web site access controls, tighter network security...
Economies for distributed IT - reduced administration, access to
better information feeds, easier integration of departmental
applications into campus-wide use...
Improved services for students and faculty - access to scholarly
information, control of personal data, reduced legal exposures...
Participation in future research environments - Grids,
Videoconferencing, etc.
Participation in new collaborative initiatives - DoD, Shibboleth,
etc.
ARKNet 2001
What are the costs to the institution?
Modest increases in capital equipment and staffing
requirements for central IT
Considerable time and effort to conduct campus wide planning
and vetting processes
One-time costs to retrofit some applications to new central
infrastructure
One-time costs to build feeds from legacy source systems to
central directory services
The political wounds from the reduction of duchies in data and
policies
ARKNet 2001
OIDs to reference identifiers
Numeric coding to uniquely define many middleware elements,
such as directory attributes and certificate policies.
Numbering is only for identification (are two oids equal? If so,
the associated objects are the same); no ordering, search,
hierarchy, etc.
Distributed management; each campus typically obtains an
“arc”, e.g. 1.3.4.1.16.602.1, and then creates oids by extending
the arc, e.g 1.3.4.1.16.602.1.0, 1.3.4.1.16.602.1.1,
1.3.4.1.16.602.1.1.1
More info at: http://middleware.internet2.edu/a-brief-guide-toOIDs.doc
ARKNet 2001
Major campus identifiers
UUID
Netid
Student and/or emplid
Email address
Person registry id
Library/deptl id
Account login id
Enterprise-lan id
Publicly visible id (and
pseudossn)
Student ID card
Pseudonymous id
ARKNet 2001
General Identifier Characteristics
Uniqueness (within a given context)
Dumb vs intelligent (i.e. whether subfields have meaning)
Readability (machine vs human vs device)
Affordance (centrally versus locally provided)
Resolver approach (how identifier is mapped to its associated object)
Metadata (both associated with the assignment and resolution of an identifier)
Persistence (permanence of relationship between identifier and specific object)
Granularity (degree to which an identifier denotes a collection or component)
Format (checkdigits)
Versions (can the defining characteristics of an identifier change over time)
Capacity (size limitations imposed on the domain or object range)
Extensibility (the capability to intelligently extend one identifier to be the basis
for another identifier).
ARKNet 2001
Important Characteristics
Semantics and syntax- what it names and how does it name it
Domain - who issues and over what space is identifier unique
Revocation - can the subject ever be given a different value for
the identifier
Reassignment - can the identifier ever be given to another
subject
Opacity - is the real world subject easily deduced from the
identifier - privacy and use issues
ARKNet 2001
Identifier Mapping Process
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
A key first step towards the loftier middleware goals
ARKNet 2001
Authentication Options
Password based
• Clear text
• LDAP
• Kerberos (Microsoft or K5 flavors)
Certificate based
Others - challenge-response, biometrics
Inter-realm is now the interesting frontier
ARKNet 2001
Cuttings: Authentication
User side management - crack, change, compromise
Central side password management - change management,
OS security
First password assignment - secure delivery
Policies - restrictions or requirements on use
ARKNet 2001
Some Authentication Good Practices
Pre-crack new passwords
Pre-crack 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
USmail a one-time password (time-bomb)
In-person with a photo id (some require two)
For remote faculty or staff, an authorized departmental rep in
person coupled with a faxed photo-id.
Initial identification/authentication will emerge as a critical
component of PKI
ARKNet 2001
Directory Issues
Applications
Overall architecture
• Chaining and referrals, Redundancy and Load Balancing,
Replication, synchronization, Directory discovery
The Schema and the Directory Information Tree (DIT)
• attributes, ou’s, naming, object classes, groups
Attributes and indexing
Management
• clients, delegation of access control, data feeds
ARKNet 2001
Directory-enabled Applications
Email
Account management
Web access controls
Portal support
Calendaring
Grids
ARKNet 2001
A Campus Directory Architecture
Border
directory
Metadirectory
Enterprise
directory
Departmental
directories
Dir
DB
Registries
OS directories
(MS, Novell, etc)
Source
systems
ARKNet 2001
Key Architectural Issues
Interfaces and relationships with legacy systems
Performance in searching
Binding to the directory
Load balancing and backups are emerging but proprietary
Who can read or update what fields
How much to couple the enterprise directory with an operating
system
http://www.georgetown.edu/giia/internet2/ldap-recipe/
ARKNet 2001
Schema and DIT Good Practices
People, machines, services
Be very flat in people space
Keep accounts as attributes, not as an ou
Replication and group policies should not drive schema
RDN name choices rich and critical
Other keys to index
Creating and preserving unified name spaces
ARKNet 2001
Attribute Good Practices
INetOrgPerson, eduPerson, localPerson
Never repurpose an RFC defined field; add new attributes
Adding attributes is easier than thought
Keep schema checking on, unless it is done in the underlying
database; watch performance
Most LDAP clients do not treat multi-valued attributes well, but
doing multiple fields and separate dn’s no better.
ARKNet 2001
Management Good Practices
No trolling permitted; more search than read
LDAP client access versus web access
Give deep thought to who can update
Give deep thought to when to update
LDIF likely to be replaced by XML as exchange format
Delegation of control - scalability
“See also”, referrals, replication, synchronization in practice
Replication should not be done tree-based but should be filtered
by rules and attributes
ARKNet 2001
PKI
First thoughts
Fundamentals - Components and Contexts
The missing pieces - in the technology and in the community
Higher Ed Activities (CREN, HEPKI-TAG, HEPKI-PAG,
Net@edu, PKI Labs)
ARKNet 2001
PKI: A few observations
Think of it as wall jack connectivity, except it’s connectivity for
individuals, not for machines, and there’s no wall or jack…But 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.
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.
ARKNet 2001
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...
ARKNet 2001
PKI Components
X.509 v3 certificates - profiles and uses
Validation - Certificate Revocation Lists, OCSP, path
construction
Certificate 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
ARKNet 2001
PKI Contexts for Usage
Intracampus
Within the Higher Ed community of interest
In the Broader World
ARKNet 2001
PKI Implementation Options
In-source - with public domain or campus unique
In-source - with commercial product
Bring-in-source - with commercial services
Out-source - a spectrum of services and issues
what you do depends on when you do it...
ARKNet 2001
What Isn’t Here Yet…
Certificate Policies and Practice Statements
Inter-realm trust structures
Mobility
ARKNet 2001
The Gathering Clouds
aka Tightly-Knit Vapor
PKI - the research labs and HEPKI-TAG, PAG
eduPerson
the Directory of Directories
Shibboleth
Medical Middleware
ARKNet 2001
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
ARKNet 2001
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 conf 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 conf calls, email archives
ARKNet 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 Wisconsin
HEPKI-TAG and PAG - Jim Jokl (Virginia) and Ken Klingenstein (Colorado)
HEBCA - Mark Luker (EDUCAUSE)
Medical Middleware - Rob Carter (Duke)
Opportunities - video, the GRID, K-12
ARKNet 2001
Early Harvest and Early Adopters
Early harvest in the barn…
http://middleware.internet2.edu/best-practices.html
Early adopters aggressively doing deployments
http://middleware.internet2.edu/earlyadopters
MTU, UMBC, JHU
http://www.colorado.edu/committees/DirectoryServices/
ARKNet 2001
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-recipe/
ARKNet 2001
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.
Presumes campuses to add local person objectclass.
A joint effort of EDUCAUSE and I2
ARKNet 2001
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.)
ARKNet 2001
Examples of eduPerson Attributes
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
eduPersonPrinicipleName
• 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 make sure what the reassignment policy is.
ARKNet 2001
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]
ARKNet 2001
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 dn’s)
Michael Gettes, Georgetown, project manager
ARKNet 2001
Metadirectories
Metamerge – product available free of charge to Higher Ed in USA
Higher Ed contact in USA: Keith Hazelton, University of Wisconsin
[email protected]
Source code will be in escrow.
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
ARKNet 2001
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):
ARKNet 2001
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 done; architecture next; implementation by fall
Strong partnership with IBM to develop and deploy
http://middleware.internet2.edu/shibboleth
ARKNet 2001
Isn’t 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 don’t 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...
ARKNet 2001
Related Work
Previous DLF work
http://www.clir.org/diglib/presentations/cnis99/sld001.htm
OASIS Technical Committee (vendor activity, kicked off 1/2001)
http://www.oasisopen.org/committees/security/index.shtml
http://lists.oasis-open.org/archives/security-services/
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
ARKNet 2001
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!
ARKNet 2001
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
ARKNet 2001
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.
ARKNet 2001
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 . .)
ARKNet 2001
Shibboleth Architecture
Concepts - High Level
Pass content if user is allowed
Authorization Phase
Target
Web
Server
Browser
Authentication Phase
First Access - Unauthenticated
Origin Site
Target Site
ARKNet 2001
Shibboleth Architecture
Concepts (detail)
Authentication
Authorization
Success!
Phase
Entitlements
Attribute
Server
Ent Prompt
Req Ent
Web Login
Server
Target
Web
Server
Browser
Auth OK
Authentication
Second Access - Authenticated
Pass entitlements for authz decision
Redirect
Pass content
User toifLocal
user Web
is allowed
Login
Ask to -Obtain
Entitlements
First Access
Unauthenticated
Origin Site
Target Site
ARKNet 2001
Shibboleth Architecture
Concepts #1 (managing trust)
Club Shib
Server (holds
certs and
contracts)
Attribute
Server
Shib
htaccess
plugin
Target
Web
Server
Browser
Origin Site
Target Site
ARKNet 2001
OASIS Charge
Standardize:
• an XML format for "assertions" of both names/identities and
entitlements/privileges/attributes
• a 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
ARKNet 2001
Entitlements
A set of Assertions
[email protected]
“active member of the community”
“active in course X”
member of group “georgetown.giia
?
Signed by the institution!
ARKNet 2001
Personal Privacy
Personal Information is released to site X based on:
• Contract provisions
• Current request from the target
• User control!
ARKNet 2001
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”)
ARKNet 2001
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
ARKNet 2001
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.
ARKNet 2001
Internals of the Shibboleth Model:
Services, standards, protocols
Identifier
privacy engine
Web access
control
service
Where from
service
OASIS XML Standard
Credential
Factory
Local
authentication
service
Web
SSO
service
Institutional shib key
distribution service
Interrealm information exchange
protocols for authn
and authz
Local Shibboleth
control point
Local attribute server
ARKNet 2001
Descriptions of services
Local authn server - assumed part of the campus environment
Local web sso server
Local web access control tools (eg htaccess)
Credential factory - assembles/disassembles signed XML objects using
attribute servers
Local attribute server - an LDAP directory, or roles database or….
Where from service - one possible way to direct external users to their
own local authn service
Privacy identifier engine - one possible way to manage identifiers to
protect privacy
Local Shib control point - to coordinate/config/manage Shibboleth
services
Institutional Shib key distribution service- a way to manage interinstitutional exchange of signing keys
ARKNet 2001
Project Status/Next Steps
Requirements and Scenarios document nearly finished
IBM and Mace-Shibboleth are refining architecture and
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 and access control, remote resource attribute
discovery).
Technical design complete - April, 2001
Coding...
Pilot site start-up - Aug, 2001
Public demo - Internet2 Fall Member Meeting 2001
ARKNet 2001
Shibboleth, eduPerson, and
Middleware
Inputs & Outputs
everything else
Licensed
Resources
Grids
OKI
Embedded
App Security
JA-SIG &
uPortal
Inter-realm
calendaring
Shibboleth, eduPerson, Affiliated Dirs, etc.
Campus
web sso
Enterprise
Directory
Enterprise
Authentication
futures
Enterprise
authZ
Legacy
Systems
ARKNet 2001
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
ARKNet 2001
HEPKI-TAG
Chaired by Jim Jokl, Virginia
Certificate profiles
• survey of existing uses
• development of standard presentation
• identity cert standard recommendation
Mobility options - SACRED scenarios
Public domain software alternatives
ARKNet 2001
HEPKI-PAG
David Wasley, U California, prime mover
Draft certificate policy for a campus
HEBCA certificate policy
FERPA
State Legislatures
Gartner Group Decision Maker software
ARKNet 2001
Medical Middleware
Unique requirements - HIPAA, disparate relationships, extended
community, etc.
Unique demands - 7x24, visibility
PKI seen as a key tool
MaceMed recently formed to explore the issues
ARKNet 2001
The complex challenges of
academic medical middleware
Intrarealm issues - multiple vendors, proprietary systems,
evolving regulations
Enterprise issues - security, directories, authorization; balance
of institutional and medical enterprises
Interrealm 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.
ARKNet 2001
The enterprise architect view of
medical middleware
Medical
Administrative
Systems
Research
Systems
Hospital
Administrative
Systems
Internet
App
dir
LAN dir
Institutional
Student
Financial
Personnel
Systems
Person registry
Border
Directory
Enterprise directory
Authentication
Services
Peer
institutions
Corporate
collaborators
PKI
Authorization
Services
Federal
State
Gov’ts
ARKNet 2001
What’s On the Horizon
Video and portals
Grid integration
K-12
ARKNet 2001
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
ARKNet 2001
More information
Early Harvest / Early Adopters http://middleware.internet2.edu/earlyadopters/
Mace - middleware.internet2.edu
LDAP Recipe - http://www.georgetown.edu/giia/internet2/ldaprecipe/
Eduperson - www.educause.edu/eduperson
Directory of Directories - middleware.internet2.edu/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
ARKNet 2001