Embed Size (px)
Citation preview
Middleware Tutorial and Use
Renee Woodten Frost
Project Manager, Internet2 Middleware Initiative
Internet2 Middleware Liaison, University of Michigan
ARKNet 2001 28 March 2001
ARKNet 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 in-person 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
Univ of Hawaii
Johns Hopkins Univ
Univ of Maryland, Baltimore County
Univ of Memphis
Univ of Michigan
Michigan Tech Univ
Univ of Pittsburgh
Univ of Southern California
Tufts Univ
Univ of Tennessee Health Science Center, Memphis
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 campus-based 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
Network-layer middleware
Core middleware
AcademicComputingUpperware
ResearchOriented
Upperware
BusinessUpperware
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-to-OIDs.doc
ARKNet 2001
Major campus identifiers
UUID
Student and/or emplid
Person registry id
Account login id
Enterprise-lan id
Student ID card
Netid
Email address
Library/deptl id
Publicly visible id (and pseudossn)
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
Account management
Web access controls
Portal support
Calendaring
Grids
ARKNet 2001
A Campus Directory Architecture
Metadirectory
Enterprisedirectory
DirDB
Departmentaldirectories
OS directories(MS, Novell, etc)
Borderdirectory
Registries Sourcesystems
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 Cloudsaka 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
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 deployhttp://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.oasis-open.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
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
ARKNet 2001
Second Access - Authenticated
Target Web
Server
Origin Site Target Site
Browser
First Access - Unauthenticated
Web Login Server
Redirect User to Local Web Login
Ask to Obtain Entitlements
Pass entitlements for authz decision
Pass content if user is allowedAuthentication
AttributeServer
Entitlements
Auth OK
Req Ent
Ent Prompt
Authentication Phase
Authorization Phase
Success!
Shibboleth ArchitectureConcepts (detail)
ARKNet 2001
Target Web
Server
Origin Site Target Site
Browser
AttributeServer Shib
htaccessplugin
Club Shib Server (holds
certs and contracts)
Shibboleth ArchitectureConcepts #1 (managing trust)
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
“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
Local authentication
service
OASIS XML Standard Interrealm information exchangeprotocols for authn
and authz
Local Shibbolethcontrol point
Web accesscontrolservice
Web SSO
service
Institutional shib keydistribution service Where from
service
Identifierprivacy engine
CredentialFactory
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 inter-institutional 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
Middleware Inputs & Outputs
GridsGridsJA-SIG &JA-SIG &
uPortaluPortalOKIOKI
Inter-realmInter-realmcalendaringcalendaring
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
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
Person registry
Enterprise directory
Appdir
BorderDirectory
LAN dir
InstitutionalStudentFinancialPersonnelSystems
MedicalAdministrativeSystems
HospitalAdministrativeSystems
Peer institutions
PKI
AuthenticationServices
FederalStateGov’ts
Corporatecollaborators
Internet
Research Systems
AuthorizationServices
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/ldap-recipe/
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
