MyVOCS My Virtual Organization Collaboration System John-Paul Robinson Jill Gemmill Jason Lynn

1. MyVOCS My Virtual Organization Collaboration System John-Paul Robinson Jill Gemmill Jason Lynn Universty of Alabama at Birmingham Office of the Vice President of Information Technology Academic Computing

2. What We'll Cover • System Design Overview • System Tour • Future Work

3. 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

4. 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

5. 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.

6. 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

7. High-level Picture of Environment

8. Diagram of System Environment

9. 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

10. 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

11. 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.

12. 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

13. Touring the System • VO Core • VO Directory • Account Initialization • VO Activities • Joining a VO • Creating a VO • Managing a VO • VO Applications

14. 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

15. Navigating the VO Name Space Goto Browser

16. 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

17. Account Initialization Goto Browser

18. 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?

19. 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

20. Account Initialization Goto Browser

21. 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

22. 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

23. 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

24. 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”

25. Joining a VO Goto Browser

26. 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

27. Creating a VO Goto Browser

28. 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.

29. 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

30. Changing Roles Goto Browser

31. 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

32. 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

33. Behavior Varies with VO Application Goto Browser

34. 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

35. 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

36. 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.

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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.

43. 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

44. 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

45. 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

46. 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. ;)

47. Try the Demo • Play with the system here: • http://webapp.lab.ac.uab.edu/sympa • Have questions, send them here: • jpr@uab.edu

48. Questions?