MyVOCS

My Virtual Organization Collaboration System

John-Paul RobinsonJill GemmillJason Lynn

Universty of Alabama at BirminghamOffice of the Vice President of Information Technology

Academic Computing

What We'll Cover

● System Design Overview● System Tour● Future Work

What We Wanted

● Virtual Organization Collaboration Environment for the UABgrid

● Communication -- Email● Data Organization -- CMS● Collaborative Editing -- Wiki● Document Sharing -- File Manager

● Demonstrate Utility of Middleware ● Leverage existing open source applications● Use middleware in familiar application contexts● Engage developer communities

Requirements

● Leverage institutional identity ● Support inter-institutional collaborations● Centrally defined membership lists and

roles● Central attributes shared across

application and system administration boundaries

● VO autonomy from attribute stores out of their administrative control

In a Nutshell

● Create an environment that enables collaborations among a relatively small part of the population which can cross organizational boundaries for users that don't have administrative authority over anything but their own VO and it's associated resources.

The Model in Our Mind

● Helpful metaphor is desktop experience on a multi-user platform

● Can move seamlessly from one application to the next and each respects your identity by trusting the identity and group info they are given from a central attribute store which is made available because they trusted the login program to authn you.

● The model is Unix● Unix is a good model because from it's earliest

days it was successfully used to enable collaborations.

● Has the abstractions needed for a complete system environment

High-level Picture of Environment

Diagram of System Environment

A Note on Terminology

● To discuss the two sides of this application space, some terms need to be clarified

● General or loose patterns ● “vo” prefix to identify a component that is

internal to the VO Shibboleth space, eg. “vocore” and “voapp”

● Alternate between the use of “VO” and “list”. ● “list” is a vo definition as well as a

communication service● The terminology is still evolving

What We Chose

● Use Shibboleth for the inter-application, cross-organizational, attribute transfer

● Use mailing list management software as the foundation or core of the VO environment

● Use existing open source tools with established use as collaboration tools

● Didn't want to build the environment from scratch● If designed correctly, would be able to incorporate

interesting new applications in the future

Why Pick a Mailing List Manager?

● Mailing lists are common tool for enabling cross-organizational collaborations

● Mailing list software has correct procedural abstractions for membership and roles

● Users self register for membership in list ● List owner has privileges to manage own list, he

is the vo administrator● Moderated list/group membership possible

● Enables a single service to host many distinct communities.

Why Pick Sympa?

● Established mailing list package● Support for Shibboleth● Has complete UI for interacting with list

for list users and list owners● Nicely integrated with MTA so creating

a list/vo doesn't require admin intervention.

● SQL backend allowing 3rd party access● Could use shibboleth AA out of the box

Touring the System

● VO Core● VO Directory● Account Initialization

● VO Activities ● Joining a VO● Creating a VO● Managing a VO

● VO Applications

Navigating the VO Name Space

● Published list of VOs● Categories of VOs● Pick a VO to access it's main page

● This is part of the vocore service● Similar concept to the Yahoo! directory

Navigating the VO Name Space

Goto Browser

Account Initialization

● Initialization Step● Maps institutional identity to VO identity● Collect minimum required information for a

working VO environment (name/email)● Required only once, subsequent logins are

automatic ● Should be viewed as as the vocore setup

wizard for individual users.● Remember: model is desktop application space.

It's fairly common that the first time you use your desktop that you have to provide some data

● The vocore is a service provider in the identity federation

Account Initialization

Goto Browser

Why Prompt for Email?

● Couldn't we get all required information from the home institution?

● Isn't attribute distribution what Shibboleth is supposed to solve?

Carmody/Morgan Conundrum

● Your email as defined by your institution may not be the email you use to communicate

● It may not even be a working email address

● EduPerson can't provide assurances about authenticity of email address

● User is authoritative for this attribute

Account Initialization

Goto Browser

Logging In to the Vocore

● Once the vocore knows the mapping to your vo identity, login proceeds normally

● The mapping is maintained inside Sympa right now

● After login you are ready to participate in a VO or create one

The Dual Role of Sympa

● Sympa plays a dual role ● It is the vocore for registration and attribute

storage● It acts as a service within the VO

● Only a conceptual separation ● Leveraging an application as the vocore that is

not built with this in mind● Possible to implement from the ground up as

two very distinct applications● Possible to introduce separation of concepts

within Sympa● It's very useful to be aware of this separation in

order to leverage the tool to it's maximum

Sympa Modifications

● Sympa uses email address as the user id internally and doesn't have a distinct user identity

● Needed to added userid to email mapping in order to support use as vocore

● Doesn't interfere with standard operation of Sympa

● Only leveraged during the login process

Joining a VO

● A powerful feature of a mailing list is support for the end-user being able to join a group

● Navigate to the list's main page and join the list

● Default role is “member”

Joining a VO

Goto Browser

Creating a VO

● Creation is simple● Click on Create● Define the name, type, title, category, and

description● All VO applications are initialized during create

● Sympa can define different authorization scenarios for list creation

● Currently anyone may create a VO● Could restrict to anyone in InCommon

Creating a VO

Goto Browser

Managing VO Attributes

● VO attribute management is a direct result of management of the list

● Joining a list is how you join a virtual organization. This sets the “member” attribute

● Creating is list is how you become the owner of a virtual organization. This sets the “owner” attribute.

● Being elevated to an editor/moderator in the mailing list is how you gain edit privileges in certain voapps. This sets the “editor” attribute. Only owners may elevate privileges.

Changing Roles

● Role changes occur in the vocore for a specific VO and are changed by the VO owner

● Sympa views this as standard mailing list management

● The other voapps respond to the new role for the user and deliver a different level of service accordingly

Changing Roles

Goto Browser

Meaning of Attributes to VO Applications

● Each tool interprets attributes in a way meaningful to itself

● Need to define the behavior of each role in the different VO application

Behavior Varies with VO Application

● Wiki● Any member may modify

● CMS● Sensitive to member, editor, and owner roles

and give different privileges based on role● File Manager

● Sensitive to roles and gives different privileges based on role

Behavior Varies with VO Application

Goto Browser

Considerations for VO Applications

● What do you need to modify?● Should respect what the application is

capable of doing● Not everything is a swiss army knife● Sometimes it's best to just use a tool for what it

was designed to do● Introducing roles within an app that does have

that concept is probably more work than you want to do

● Remember the desktop: different applications do different things

Name Space Navigation

● The back button doesn't work well to move between apps

● Possible solutions● Use different browser windows for each

application and use the window or tab names to navigate

● Visual integration of application menus, could be complex

● Export application name space via RSS or similar directory publishing technologies and simple menu applications for VO

● Consider the desktop analogy

Visual Integration

● Consistent user experience● Easier if apps support template technology but

may not allow similar layouts● Basic integration could just consistently define

“Home” and “Logout” across applications and use similar logs and colors

● May not be the biggest initial hurdle since users accustomed to some variation across web apps

● Problems● Time intensive● May have to wait for other visual middleware

to advance.

Data Integration

● Tough problem in general but specific data formats are already interchangeable

● Internet-standard messages● Archive in Sympa is good for public access ● Archive in CMS is great for tagging and organizing

new content from message discussion streams● Application replacement is not really

the goal since this is a traditional data migration issue

Non-Federation Participants

● The basic solution requires that someone be willing to sponsor an identity.

● Yahoo/MSN/etc sponsor meaningless but useful identities

● A known user could sponsor an anonymous user giving them enhanced privileges and generating an audit trail

● Identification technologies like PKI-buddy systems could allow a user to become individually identified and qualify for a high quality identity from and IdP

● Need a solution for the infrastructure impoverished

Controlling the VO Attributes

● Distribute attributes for a specific VO exclusively to applications for that VO

● Shib attribute release is on a SP basis● One solution is to elevate the VO identity to a

SP identity at the VO application hosting service

● Another option may be to provide different classifications of voapp hosting services and allow policy decisions to influence if a voapp provider can host applications for a VO

Controlling the VO Application Space

● Can treat this as a distributed computation problem

● Plan to use Grid/Globus technologies under the hood to enable remote control application configuration on hosting providers

● Enables VO hosting trust relationships

VO Attribute Management

● Make it possible to record more attributes for members of the vo and define additional roles within vo

● Introduces complexities of getting the roles to transfer to other apps.

● Attribute management by vo members is one of the most compelling reasons for this arrangement, akin to tagging

Meaning of VO Attributes

● Attribute and role taxonomies and semantics could be developed at the local level by people with an immediate organizational interest in defining them

● If a vo sees the need to defining a new role they can define it an associate people with it

● Applications can then consume new role● These terms can bubble up the chain

as commonalities are discovered.

Adding Grid Resources

● Make it possible for a VO to add it's own resources

● A good example:● Enable registering a group of desktops owned

by film animation students working on different campuses so they can render their animation on their own grid resources

● Keep up with what grid-shib is doing

Define a Meta-WAYF

● In a multi-fed environment, need way for user to select which identity to use

● Effectively asking which federation they want to use

● Complicated question● But analogy to current system login id is there.

Which login account do i use? ● This is needed within the VO to direct

users to the correct identity provider

More applications!

● Want to integrate more applications● Allow users to chose what tools they

want for their VO● Better VO attribute management

● Enhance Sympa (takes it beyond what a MLM might should be, swiss army knife dangers)?

● Replace with Grouper/Signet?● More application integration.

● Almost a never-ending process● See desktop

More Documentation!

● Will be working on documenting developer notes for what issues to consider when integrating applications with middleware

● NMI R6 will include initial iteration with focus on mailing list application integration (coincidentally similar to existing env. ;)

Try the Demo

● Play with the system here:– http://webapp.lab.ac.uab.edu/sympa

● Have questions, send them here:– jpr@uab.edu

Questions?