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