my VOCS my Virtual Organization Collaboration Suite Jill

my. VOCS my Virtual Organization Collaboration Suite Jill Gemmill John-Paul Robinson Jason L. W. Lynn May 3, 2005 1

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 2

Acknowledgment John-Paul Robinson, co-PI Members of IT Academic Computing Advanced Technology Lab: * Prahalad Achutharao * Yi. Yi Chen * Silbia Peechakara * Song Zhou IT Academic Computing David L. Shealy, Director April 28, 2005 3

Key Goal Enable assembling a computing environment providing seamless access to distributed tools needed by a team of researchers with appropriate access controls l Is this “the grid”? l l l 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 4

Virtual Organizations ? A research collaboration, formed dynamically and crossing many administrative and institutional organizations. PARTICIPANT-centric organization April 28, 2005 5

What’s Important About VO’s? l NIH Roadmap (Zerhouni, 2004) l l l PITAC (“Revolutionizing Healthcare through IT” 2004) l l New, multidisciplinary approaches to analyzing very large data sets Eliminate use of 19 th century paperwork in 21 st century clinical medicine 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 6

Broader Impact l 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 7

What tools do VO’s need? l Mailing List l l MEMBERS of the VO Other open source tools : l l l l 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 8

The Virtual Organization Infrastructure Problem April 28, 2005 9

VO Challenges in a Nutshell l No common root l Multiple identity providers l Using both institutionally owned and individually owned resources l Attention to licensing issues (eg: on-line journal access) April 28, 2005 10

Middleware Issues l “Triple-A” (AAA) Identity Management (Authentication) l Access Control Rules & their use (Authorization) l Provisioning System-specific Accounts l April 28, 2005 11

Authentication Establishes who you are (Identity) l Is typically accomplished by an Identity Provider (eg, your Blazer. ID) l Leveraging these Identity Services is good l l l no reason for redundant process Higher level in confidence in identity possible Method varies: username/password; digital certificate; kerberos ticket; biometric device… l Method will not be same for each collaborator l SSO and Web. ISO services are desirable l April 28, 2005 12

Authorization l Who is allowed to do what Who=Attributes (Identity, Group, Role) l Allowed=Permission (Rule, Policy) l What=Action (Read, Write, Execute) l l Attributes+Rules Decision(Allow/Deny) l Identity is just another attribute l Example: How to combine “UAB faculty” and “IEEE member” attributes? April 28, 2005 13

Account / Accounting l System-specific resources are needed l Example: as an enrolled student you may be authorized to use UAB email service but you also need a mailbox. l This is PROVISIONING issue l Your identifier in the system is used for logging l Note: Identity <> Account April 28, 2005 14

Distributed AAA (Root Trust Model) l Trusted Third Party l root R A root authority R www. amazon. com R l R In order to: buy with confidence; have confidence you are who you say you are April 28, 2005 15

AAA Root Models (Kerberos) l Project Athena/Kerberos (1983 -1989) l l l Open Software Foundation’s Distributed Computing Environment l l l Encryption of credentials Single-sign on Identification of both server and client Scalability via Kerberos V 5 hierarchy 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 16

AAA Root Model : PKI l X. 509 (ITU and IETF standard, 1993 -1995) l l l 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 l Designed for Global PKI l l l EACH user needs AT LEAST one public/private key pair; Users must understand private key management BIG MANAGEMENT ISSUE l l l April 28, 2005 Certificate revocations Key escrow Users must understand private key management 17

AAA Root Other Models Microsoft Passport l Bridged Certificate Authorities (CA) l l l April 28, 2005 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) 18

Federation – Shibboleth (no root) l l l Internet 2 solution for attribute transport across organizations Leverages distributed Identity Providers using heterogeneous authentication systems Uses Open. SAML 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 Id. P web single sign-on “Shliberty” Liberty Alliance – federate your identity from your PINs, cookies, etc. (broader than Shib) April 28, 2005 19

Shibboleth Architecture (Web Browser Access) Identity Provider. UAB Attribute Authority AA UVa. HS Id. P AA In. Queue Federation April 28, 2005 Shibboleth Target Request Attributes Authorize Access Johns Hopkins Clinical Data HS Id. P UWisc • “UAB p er • “studen son” t” • “Queen ” HS Brown. U WAYF ? Shibboleth Origin HS UAB Apache/IIS Tomcat URL redirect Shibboleth Target AA EBSCO Journals “EBSCO Club” 20

Federation +’s and –’s l Signed X. 509 Cert is replaced by Signed SAML Assertion l l l 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 l Standardization Process not complete l Few applications available l April 28, 2005 21

VO Tools: Open Source “VO-in-a-Box” Wide Range of web-based Open Source tools available (wiki, content management, list manager, etc. ) l These applications mostly built around self-contained authentication, limited roles, and authorization handled by manual account creation l Why? l l l 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 22

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 l eg: JSR 168 Portlet specification (Open Grid Computing Environment / u. Portal / Sakai) l Typically use a proxy portal can authenticate as the user l Limitations: l l l 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 23

What is the actual goal? l To reproduce functionality of a “system” environment l l l 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: l l Where are the attributes, roles, and how trusted is this information? Supporting attributed anonymous access April 28, 2005 24

Attribute Storage issues **** l l Who is authoritative for the attribute? Where is the attribute stored? 1. 2. 3. l Put EVERYTHING into schema provided by Id. P Store attributes at multiple, authoritative sources (configure app. to search in order? ) Some combination of these two Privacy issues; user release management issues; practical programming issues…. April 28, 2005 25

Current Approaches to Attribute Mgt. l Grouper, Signet (Internet 2) l l Assign roles in order to assign roles How does this work across institutions? Grid Shib (2004) allows use of Shibbolethissued attributes for auth. Z in Globus l Peer-2 -Peer Models l l Don’t require “helpful central administrators” eg: Groove; Lionshare (leverages Id. P’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 26

Design Goals for Experiment A functional collaboration environment for a VO allowing members to work together and share documents under these conditions: l l l 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 27

Trust Issues to be Managed Organizations do not share a common root authority l Leverage use of existing, unrelated Identity providers and Web. ISO Grid VO w. Trusted CA l VO requires ability to Argonne l l l Designate its own members Create and assign its own roles/attributes Uabc UAB UMich Inqueue Federated Trust April 28, 2005 Terra. Grid Uxyz Federated The. Earth VO AA The. Earth VO No Id. P 28

Experimental Approach l l l 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 Internet 2 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 29

Experimental Setup April 28, 2005 30