; MyVOCS My Virtual Organization Collaboration System John-Paul
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

MyVOCS My Virtual Organization Collaboration System John-Paul

VIEWS: 4 PAGES: 48

  • pg 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
              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?

								
To top
;