1 myvocs my virtual organization collaboration suite jill gemmill john-paul robinson jason l. w....
TRANSCRIPT
1
myVOCSmy Virtual Organization Collaboration Suite
Jill Gemmill
John-Paul Robinson
Jason L. W. Lynn
May 3, 2005
April 28, 2005 2
Acknowledgment
This material is based upon work supported by the National Science Foundation under ANI-0330543 “NMI Enabled Open Source Collaboration Tools for Virtual Organizations” to the University of Alabama at Birmingham. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.
April 28, 2005 3
Acknowledgment
John-Paul Robinson, co-PI Members of IT Academic Computing Advanced
Technology Lab:* Prahalad Achutharao* YiYi Chen* Silbia Peechakara
* Song ZhouIT Academic Computing
David L. Shealy, Director
April 28, 2005 4
Key Goal
Enable assembling a computing environment providing seamless access to distributed tools needed by a team of researchers with appropriate access controls
Is this “the grid”? New: Federated Authentication and Authorization New: Automated Account Provisioning New: convert Open Source software to
“components” with standardized AAA interface New: no portal required
April 28, 2005 5
Virtual Organizations ?
A research collaboration, formed dynamically and crossing many administrative and institutional organizations.
PARTICIPANT-centric organization
April 28, 2005 6
What’s Important About VO’s?
NIH Roadmap (Zerhouni, 2004) New, multidisciplinary approaches to analyzing very
large data sets Eliminate use of 19th century paperwork in 21st
century clinical medicine PITAC (“Revolutionizing Healthcare through
IT” 2004) Electronic health records, order entry Security, privacy, interoperability Another very large data set!
PITAC (2004) “Computational Science is Essential to Scientific Discovery”
April 28, 2005 7
Broader Impact
Expanding role-based management, such as is found inside current relational DB’s, to distributed data elements, is important for every application area, from patient record access to neighborhood association records.
April 28, 2005 8
What tools do VO’s need?
Mailing List MEMBERS of the VO Other open source tools :
Wiki File sharing (controlled R/W) Role assignments
Sharing identity across apps Sharing attributes/roles across apps Apps that THEY have selected And maybe some integration w. grid computational
resources
April 28, 2005 9
The Virtual Organization Infrastructure Problem
April 28, 2005 10
VO Challenges in a Nutshell
No common rootMultiple identity providersUsing both institutionally owned and
individually owned resourcesAttention to licensing issues (eg: on-line
journal access)
April 28, 2005 11
Middleware Issues
“Triple-A” (AAA) Identity Management (Authentication)Access Control Rules & their use
(Authorization)Provisioning System-specific Accounts
April 28, 2005 12
Authentication
Establishes who you are (Identity) Is typically accomplished by an
Identity Provider (eg, your BlazerID) Leveraging these Identity Services is good
no reason for redundant process Higher level in confidence in identity possible
Method varies: username/password; digital certificate; kerberos ticket; biometric device…
Method will not be same for each collaborator SSO and WebISO services are desirable
April 28, 2005 13
Authorization
Who is allowed to do what Who=Attributes (Identity, Group, Role)Allowed=Permission (Rule, Policy)What=Action (Read, Write, Execute)
Attributes+RulesDecision(Allow/Deny)Identity is just another attributeExample: How to combine “UAB faculty”
and “IEEE member” attributes?
April 28, 2005 14
Account / Accounting
System-specific resources are neededExample: as an enrolled student you
may be authorized to use UAB email service but you also need a mailbox.
This is PROVISIONING issueYour identifier in the system is used for
logging Note: Identity <> Account
April 28, 2005 15
Distributed AAA (Root Trust Model)
Trusted Third Party A root authority
In order to: buy with confidence; have confidence you are who you say you are
rootR
www.amazon.com
R
R R
April 28, 2005 16
AAA Root Models (Kerberos)
Project Athena/Kerberos (1983-1989) Encryption of credentials Single-sign on Identification of both server and client Scalability via Kerberos V5 hierarchy
Open Software Foundation’s Distributed Computing Environment Introduced Remote Procedure Call Supported heterogeneous computing environment Utilized Directory Services Distributed Data Management ( Difficult to install/administer; buggy )
Windows 2000 / Active Directory
April 28, 2005 17
AAA Root Model : PKI
X.509 (ITU and IETF standard, 1993-1995) Asymmetric public/private key pair for signing and encryption (RSA
1977) Certificate Authority Used in Globus (grid toolkit) for identity (Foster, Kesselman 1997- ) Used in Secure Socket Layer (SSL)
(Dierks, Allen 1994) Legal: Electronic Signatures in Global and National Commerce Act
(E-Sign) (June 1999) Limitations
Designed for Global PKI EACH user needs AT LEAST one public/private key pair; Users must understand private key management
BIG MANAGEMENT ISSUE Certificate revocations Key escrow Users must understand private key management
April 28, 2005 18
AAA Root Other Models
Microsoft Passport Bridged Certificate Authorities (CA)
HEBCA and HEBCA-Federal Bridge (Alterman, 2002)
Bridges for Grids (Jokl, Humphrey 2004) No standardization of X.509 CONTENTS
(certificate profile) Few end-users have certificates Complex inter-institutional policies required
(non-technical)
April 28, 2005 19
Federation – Shibboleth (no root)
Internet2 solution for attribute transport across organizations
Leverages distributed Identity Providers using heterogeneous authentication systems
Uses OpenSAML based on OASIS Security Assertion Markup Language standard [OASIS-XML consortium focused on security]
“Shib Clubs” determine attributes to release and other policy issues
Leverages multiple IdP web single sign-on “Shliberty” Liberty Alliance – federate your identity
from your PINs, cookies, etc. (broader than Shib)
April 28, 2005 20
Shibboleth Architecture (Web Browser Access)
UABIdentityProviderUAB
AttributeAuthority
ShibbolethOrigin
IdP
AA
IdP
AA
BrownU
UWisc
IdP
AA
UVa.
InQueue Federation
EBSCOJournals
ShibbolethTarget
“EBSCO Club”
Johns HopkinsClinical Data
ShibbolethTarget
RequestAttributes
AuthorizeAccess
WA
YF
?
HS
HS
HS
HS
•“UAB person”•“student”•“Queen”
Apache/IISTomcatURL redirect
April 28, 2005 21
Federation +’s and –’s
Signed X.509 Cert is replaced by Signed SAML Assertion Same cryptography Semantics Inherent in SAML and OASIS activities Certificate Management is reduced by an order of
magnitude (only SERVERS REQUIRE digital certs)
Federations represent Institutions, not People Standardization Process not complete Few applications available
April 28, 2005 22
VO Tools: Open Source “VO-in-a-Box”
Wide Range of web-based Open Source tools available (wiki, content management, list manager,etc., etc.)
These applications mostly built around self-contained authentication, limited roles, and authorization handled by manual account creation
Why? Desire to create complete, stand-alone solution Too difficult to do otherwise Unfamiliar with federated model
Limitation: separate login for each tool – unrelated accounts/identity
April 28, 2005 23
VO Tools: “VO-in-a-Box” Portal Style
User-friendly, web-based access Identity and attributes shared across a set of
applications used by VO eg: JSR 168 Portlet specification (Open Grid
Computing Environment / uPortal / Sakai) Typically use a proxy portal can
authenticate as the user Limitations:
How many portals do you need today? Possibility exists for user impersonation Set of related tools included is determined by
system architect, not end user
April 28, 2005 24
What is the actual goal?
To reproduce functionality of a “system” environment Define roles Assign Users to roles Role-based access management Flexibility in object granularity Common Access control across many independent
sets of data (tables) Challenges:
Where are the attributes, roles, and how trusted is this information?
Supporting attributed anonymous access
April 28, 2005 25
Attribute Storage issues ****
Who is authoritative for the attribute? Where is the attribute stored?
1. Put EVERYTHING into schema provided by IdP
2. Store attributes at multiple, authoritative sources (configure app. to search in order?)
3. Some combination of these two
Privacy issues; user release management issues; practical programming issues….
April 28, 2005 26
Current Approaches to Attribute Mgt.
Grouper, Signet (Internet2) Assign roles in order to assign roles How does this work across institutions?
Grid Shib (2004) allows use of Shibboleth-issued attributes for authZ in Globus
Peer-2-Peer Models Don’t require “helpful central administrators” eg: Groove; Lionshare (leverages IdP’s, leaves
access control in hands of data owners; does not mix institutional control with individual control)
PGP and Diffie Hellman style cryptography (no root)
April 28, 2005 27
Design Goals for Experiment
A functional collaboration environment for a VO allowing members to work together and share documents under these conditions: Members from different organizations Access data and services using web browser Automatically provision accounts for authorized users. Implement appropriate access controls. Allow wide selection of tool choices No portal (no forced initial point of entry)
April 28, 2005 28
Trust Issues to be Managed
Organizations do not share a common root authority
Leverage use of existing, unrelated Identity providers and WebISO
VO requires ability to Designate its own
members Create and assign its
own roles/attributesInqueue
Federated Trust
UMich
UAB
Uxyz TheEarthVO
TerraGrid
Argonne
Grid VOw. Trusted CA
Uabc
No IdP
AA
FederatedTheEarth
VO
April 28, 2005 29
Experimental Approach Select some candidate open source applications (eg: list
management; file management; content management [wiki and more formal])
Design and implement an environment supporting authentication using multi-institutional authentication systems [provided by Internet2 Inqueue project]
Re-engineer applications as needed to interface with current Shibboleth communication methods; summarize lessons learned
Demonstrate persistent identity and attributes shared across applications and also distributed systems (at least two universities)
Prototype a middleware API capable of sharing persistent session information (persistent identity)
Test prototype with redesigned web-based and non-web based applications
April 28, 2005 30
Experimental Setup