Embed Size (px)
Citation preview
Lukas Hä[email protected]
Vienna, 23. November 2010
Flight VO-321 has taken offStatus update on the SWITCH Virtual Organization Pilot
© 2010 SWITCH
Presentation Outline
1. History
2. Architecture
2
3. Demonstration
4. Experiences
© 2010 SWITCH
What are Virtual Organizations?
Definition: “A Virtual Organisation (VO) is a group of individuals collaborating through the use of online services”
• (VO = People + Services)• People can be from different organizations
Example VO individuals:• Group of researchers in a research project • Students working on a semester project• Lecturers working on new e-learning content
3
© 2010 SWITCH 4
1. History
© 2010 SWITCH
Virtual Organizations at SWITCH
• Since the creation of the Internet, there has been a need to have easy tools to collaborate together
• Requests for a Virtual Organization solution have been a topic ever since we have started our AAI in 2005
• But people understand different things when talking about “Virtual Organizations”–Definition is “uselessly broad”–Term is already used in grid community–Often mixed up with Virtual Home Organization
5
© 2010 SWITCH
Phase 1: Analyze the Problem
• May 2009: Report “Supporting Virtual Organizations”• Gathered existing use cases• More than 25 interviews
–SWITCH staff members–External (university) staff members
• Conducted a survey
6
© 2010 SWITCH
Findings of Phase 1 Report
• We realized the growing importance of this topic!
• Discovered our target group:–Project group of 5-10 people (“dummies”)–Most VOs probably exist 6-12 months–Importance of roles and structure depends on VO size
• Three basic services needed by most VOs:–Wiki–Mailing list–Document storage
7
© 2010 SWITCH
Phase 2: Propose a Solution
• June 2009:Chad la Joie proposed an architecture– See https://spaces.internet2.edu/display/[email protected]/VOPlatform
–Basis is Shibboleth and Attribute Aggregation–No appliance-like fully integrated solution–Fully federated! Shibboleth-only (no other APIs/libraries)
• SWITCH set up a Proof-of-Concept–Also tested with other IdPs in GEANT JRA3-T2
• Chad/ITUMI started design and implementation
8
© 2010 SWITCH
Phase 3 (now): Test and Improve Solution
Pilot• Public Pilot has started in October for SWITCHaai
–See http://www.switch.ch/vo
• Pilot will last about half a year• Evaluation/feedback mid December and end February
Development• SWITCH is continuing development of the code• Code reviews are planned in January and February
9
© 2010 SWITCH
Phase 4: Productionalize Solution
• Pilot phase ends in February 2011
• Production service should start in March 2011
• Code probably will become open source–Still matter of discussion
10
© 2010 SWITCH 11
2. Architecture
© 2010 SWITCH
Concept and Architecture
• VO = People + Services• Services can be subscribed by VOs
–And maybe even paid for in the future
• Every VO can run and add its own services–Optimally all VO services will be operated by VOs themselves
• Adding new VO-Services should not require much efforts–Only few configuration changes–Optimally no changes in software
• SWITCH initially operates three basic services–In order to solve chicken-egg problem: No services, no people
12
© 2010 SWITCH
What are the Problems to Solve?
• Membership: Users are from different Home Organisations–Authentication already is solve by AAI
• Authorization: Only members of a VO should be able to access their services –How to determine whether somebody is a member of a VO?–This is the main problem to solve!
• Services: Should be able to use VO information–Adapting existing services requires quite some efforts
13
Authorization for larger groups like a VO is manageable for users that share common attribute values
© 2010 SWITCH
Scenario Where Authorization Is Easy
14
AuthType ShibbolethShibRequireSession OnShibRequireAllrequire homeOrg idpX.ch idpY.ch idpZ.chrequire affiliation studentrequire studyBranch medicine
IdP X IdP Z
IdP Y
SP
Medicine students
Other users
VO members never share a common attribute ! That’s a challenge and that’s the problem to solve
© 2010 SWITCH
More Common Authorization Scenario
15
IdP X IdP Z
IdP Y
SP
Idea: Members of a VO are given a common attribute. This (VO) attribute represents membership in a VO.
© 2010 SWITCH 16
Approach for Authorization in VOs
VO Attribute:isMemberOf=VO1
isMemberOf=VO1;VO2;VO3
isMemberOf=VO2
isMemberOf=VO1;VO3
AuthType Shibboleth
ShibRequireSession On
require isMemberOf VO2
VO1
VO2
VO3
© 2010 SWITCH 17
How to Add a Common Attribute?
VO Service Provider must aggregate attributes!
1. User’s Home OrganisationAttributes are set by user’s Home Organisation
2. VO Platform(s)Attributes are set by VO administrator
Home Organisation
User IdP
Attributes
Attributes
! SP receives aggregated set of attributes
1.
3.2.
VO Platform
VOIdP
VO Service
SP Application
© 2010 SWITCH
Infrastructure and Available User Information
18
VO Platform
Core
DB
Comato
UniA
UniB
UniC
Wiki
Mailing list
File storage
Calendar
ForumGrid Access
Example Virtual Organization
Identity-InformationID: 3249csj3409Name: Hans MusterEmail: [email protected]
Membership-InformationID: 3249csj3409VO: Example-VOGroups: Dozent, Forscher
AvailableUserInformationID: 3249csj3409Name: Hans MusterEmail: [email protected]: Example-VOGroups: Dozent, Forscher
+
© 2010 SWITCH 19
The Involved ComponentsHome Organisation
User IdP
• Home Organisation:Authenticates user and asserts basic identity information
• Virtual Organization Services:Used by VO members in order to perform their work. Could be wikis, calendars, etc.
• Virtual Organization Platform:Set of software to manage VOs and their members. Interacts with Virtual Organization Services.
SP ApplicationSP Application
VO Service
SP Application
VO Platform
VO1
IdPAA
SP
VO2 VON...
PlatformLogic DB
VO GUI
© 2010 SWITCH
VO Platform: The Missing Piece
• Is the key component for VO administration
• Basically manages the membership information in DB
• No custom-tailored solution have existed yet
20
VO Platform
VO1
IdPAA
SP
VO2 VON...
PlatformLogic DB
VO GUI
© 2010 SWITCH
VO Platform: General Design Ideas
• Design GUI as easy as possible–See following slides
• Separate GUI from logic –Logic provides a well-defined HTTP interface–Allows creating GUIs with different views or themes–Allows other services to access VO Platform data
• Only support groups within VOs–Users are most familiar with groups–Roles and privileges add complexity and confusion
21
© 2010 SWITCH
VO Platform: The Components
22
VO Platform
Apache
MySQL DB
ShibbolethIdentity Provider
Comato (GUI)
Core (Logic + Interface)
Non-Web VO Service(e.g. Mailinglist)
User
ShibbolethService Provider
Port 8443, SOAP access, /idp/*X.509 Client Authentication
Port 443, access, /core/*Basic Authentication
80, HTTP access, /core/*Restrict access to localhost
Header name: Authentication
Shibboleth Service
Provider
Port 443, GUI access, /comato/*Shibboleth Authentication
Header name: AuthenticationUses REMOTE_USER
from Basic Authentication
Latch
Developed ourselves
© 2010 SWITCH
COMATO: The VO Management Web Interface
• (Stateless) web interface to manage VOs• Implemented in Ruby-On-Rails
–But could also be implemented in JavaScript only using Sproutcore
• JRuby allows running the project as java servlet–Allows easier deployment
• Accesses the Core interface to do most of the work• Uses the word “Combo” instead ”Virtual Organization”
23
© 2010 SWITCH
COMATO: The Making Of
Designed in several months by three prospective UI specialists
24
© 2010 SWITCH
COMATO: Personas
• Facilitate defining the procedures for different user types
25
© 2010 SWITCH
COMATO: More Behind the Scenes
• Even specific interface elements were carefully chosen
26
© 2010 SWITCH
CORE: The Business Logic
• Programmed in Java using the Spring 3.0 framework• Uses Java Persistence API
–Only few adaptations necessary to use almost any database
• Was designed to be very generic –Prospect of becoming open source project
• Provides a HTTP REST interface• Uses Model/View/Controller pattern
27
© 2010 SWITCH
CORE: The Interface (i)
• A few dozens HTTP functions. E.g
•
28
© 2010 SWITCH
CORE: The Interface (ii)
• Expects and returns JSON data. For example.
29
Content-Type: application/json
POST http://vo.example.org/vos{key: ”linalg11”enrollmentType: "Closed”entityId: http://vo.example.org/linalg11publicVO: true}
© 2010 SWITCH
VO Services
SWITCH provides four basic services• Wiki: Domesticated Dokuwiki (one instance per VO)• Mailinglist: Domesticated Sympa• Document management system: Modified LetoDMS• Attribute Viewer: For debugging
Goal was to choose very simple web applications.No interface harmonization has been done yet.
30
© 2010 SWITCH
Latch: Drawer for VOs
• A piece of JavaScript displaying VO-relevant information–In which VO one is logged in–Which services one has access to in this VO–(maybe later) Activity stream of what is happening
• Works a bit like Google Ads
• Should be very easy to integrate into VO-Services
31
© 2010 SWITCH
Latch: Drawer for VOs
• A piece of JavaScript displaying VO-relevant information–In which VO one is logged in–Which services one has access to in this VO–(maybe later) Activity stream of what is happening
• Works a bit like Google Ads
• Should be very easy to integrate into VO-Services
31
© 2010 SWITCH
Latch: Drawer for VOs
• A piece of JavaScript displaying VO-relevant information–In which VO one is logged in–Which services one has access to in this VO–(maybe later) Activity stream of what is happening
• Works a bit like Google Ads
• Should be very easy to integrate into VO-Services
31
© 2010 SWITCH 32
3. Demonstration
© 2010 SWITCH
Demonstration
33
© 2010 SWITCH 34
4. Experiences
© 2010 SWITCH
About the Pilot
Goals• Verify that approach is working and accepted by users• Find out how it feels to work in a VO• Get user feedback to extend and improve the software
Current Status• 12 Virtual Organizations (many of them by SWITCH)• 4 available services: wiki, mailing list, document storage• 17 users from 4 different organizations
35
© 2010 SWITCH
Current experiences and issues (i)
General• The devil lies - as usual - in the details!• Concept and technology of our approach is complex
–It took quite some time for all involved people to understand it
36
© 2010 SWITCH
Current experiences and issues (ii)
Organizational• How do users know how to access the services?
–HomeURL is missing in metadata–Is needed to allow displaying list of subscribed VO services
• Handling of “homeless” users is not that easy–A VO admin cannot know if an invited user has an AAI account or not
37
© 2010 SWITCH
Current experiences and issues (iii)
Technical• Not clear yet which attributes to use best for reflecting VO and group membership
• It was too early to use persistentId NameID as SharedID–Support for AffiliationDescriptor of Shibboleth IdP 2.2 is prerequisite–One IdP had upgraded yet to Shibboleth IdP 2.2 when pilot started
• Using the persistentId requires metadata changes–Propagation delay of 1-2 hours after VO creation–Use of MDX (dynamic metadata retrieving) will solve this problem
38
© 2010 SWITCH
Current experiences and issues (iv)
Usability• Back-button problem when switching services
–Change from VO Service A to VO Service B -> Error–Work-around, use Artifact profile
• Consistency of VO Services–All services look different, which might be confusing for users–This is not easy to solve
39
© 2010 SWITCH
More Information
• Pilot home pagehttp://www.switch.ch/vo
• Public Project web pagehttps://forge.switch.ch/redmine/projects/vo-pilot/
40
