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

2. April 28, 20052 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.

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

4. April 28, 20054 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

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

6. April 28, 20056 What’s Important About VO’s? NIH Roadmap (Zerhouni, 2004) New, multidisciplinary approaches to analyzing very large data sets Eliminate use of 19 th century paperwork in 21 st 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”

7. April 28, 20057 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.

8. April 28, 20058 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

9. April 28, 20059 The Virtual Organization Infrastructure Problem

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

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

12. April 28, 200512 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

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

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

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

16. April 28, 200516 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

17. April 28, 200517 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

18. April 28, 200518 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)

19. April 28, 200519 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)

20. April 28, 200520 Shibboleth Architecture (Web Browser Access) UAB Identity Provider UAB Attribute Authority Shibboleth Origin IdP AA IdP AA BrownU UWisc IdP AA UVa. InQueue Federation EBSCO Journals Shibboleth Target “EBSCO Club” Johns Hopkins Clinical Data Shibboleth Target Request Attributes Authorize Access WAYF ? HS “UAB person” “student” “Queen” Apache/IIS Tomcat URL redirect

21. April 28, 200521 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

22. April 28, 200522 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

23. April 28, 200523 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

24. April 28, 200524 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

25. April 28, 200525 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….

26. April 28, 200526 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)

27. April 28, 200527 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)

28. April 28, 200528 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/attributes Inqueue Federated Trust UMich UAB Uxyz TheEarth VO TerraGrid Argonne Grid VO w. Trusted CA Uabc No IdP AA Federated TheEarth VO

29. April 28, 200529 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

30. April 28, 200530 Experimental Setup