1. AAI-enabled VO Platform “VO without Tears” Christoph Witzig christoph.witzig@switch.ch EGI TF, Amsterdam, Sept 15, 2010

2. © 2010 SWITCH 2 Outline Introduction AAI and VO: The SWITCH approach Technical Solution Roadmap and Summary Appendix: Email Enrollment

3. © 2010 SWITCH 3 SWITCHaai Federation in Spring 2010 # AAI enabled accounts # Resources # Home Organizations >96% coverage in higher education

4. © 2010 SWITCH Access to AAI Resources 3

5. © 2010 SWITCH Use-case: Access to SP within AAI Federation 5 AuthType Shibboleth ShibRequireSession On ShibRequireAll require homeOrg idpX.ch idpY.ch idpZ.ch require affiliation student require studyBranch medicine Medicine students Other users Example: Access of medical students to a common SP Authorization based on attributes released by IdP

6. © 2010 SWITCH Use-case: Access for Arbitrary Groups Formulating access rules becomes cumbersome for arbitrary groups in different institutions  concept of virtual organization (VO) Note: Most VOs need very simple services –Mailing lists –Wiki –Document store –… and many of these services already support Shibboleth! 6

7. © 2010 SWITCH Virtual Organization Virtual organization (VO) is needed for –Enabling access based on attributes not tied to the „home organization“ What does virtual organization need? –VO specific services –Authentication –Access control / authorization –Management of VO-specific attributes 7

8. © 2010 SWITCH 8 Outline Introduction AAI and VO: The SWITCH approach Technical Solution Roadmap and Summary Appendix: Email Enrollment

9. © 2010 SWITCH AAI and VO: SWITCH Approach (1/2) Basic Idea: Keep it as simple as possible - “VO without Tears” Requirements: –Many Services are already AAI-enabled  only minimal configuration changes should be needed in order to VO-enable a service  SAML2 as basis –Interactions between home organization and VO is completely hidden for the user  Authentication done by Home Organization  user uses well-known AAI credentials –Administrator of home organization is not involved  IT services do not want to administrate VO specific attributes –Administration of VO must be easy – done by VO admins 9

10. © 2010 SWITCH 10 AAI and VO: SWITCH Approach (2/2) SP aggregates attributes: 1. From user’s Home Organisation Attributes are set by IdP admin 2. From VO Platform(s) Attributes are set by VO admin User is identified by an attribute that is used as shared ID ‣ Augmented set of attributes available at VO SP

11. © 2010 SWITCH 11 Components Needed Home Organization: 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.

12. © 2010 SWITCH 12 Outline Introduction AAI and VO: The SWITCH approach Technical Solution Roadmap and Summary Appendix: Email Enrollment

13. © 2010 SWITCH 13 How to Identify User between IdP and VO? Shared ID must be known at user IdP, VO services SP and VO platform Value of shared ID is used in SAML 2 Persistent Name Identifier of attribute request Option 1: Value of common identifier attribute like eduPersonPrincipalName, email address or similar –Easy to implement and already works today –Problematic if used for multiple VOs that span multiple organizations due to data correlation attacks (SP A from VO 1 and SP B from VO 2 could merge data) Option 2: Use value of persistentID that is generated by the IdP for an SP or group of VO SPs using an Affiliation descriptor in metadata

14. © 2010 SWITCH 14 Architecture Overview

15. © 2010 SWITCH 15 How to enroll users to a VO? Self-enrollment: Open or using a password Manual enrollment: User requests to join a VO. Request then has to be approved or rejected by a VO administrator Email-enrollment (most likely): Email invitation with a one-time token –See appendix

16. © 2010 SWITCH 16 Advantages of this VO approach No additional protocols required –It’s pure SAML 2 and Shibboleth supports all that is required Simple configuration on VO SP –Add approximately 4 lines to enable attribute aggregation on an SP No API/Library needed to access VO Attributes –VO service applications get access to VO attributes the same way as any other Shibboleth attribute. No special API/Library required. Access control works out of the box with Shibboleth. Easy to query multiple VO Platforms –Statically or dynamically (based on an attribute values) configured

17. © 2010 SWITCH 17 Outline Introduction AAI and VO: The SWITCH approach Technical Solution Roadmap and Summary Appendix: Email Enrollment

18. © 2010 SWITCH 18 Roadmap VO Platform is currently being implemented by SWITCH –Design and partial implementation Itumi PLC (C. La Joie) SWITCH adapts and initially operates 3 core VO Services –Wiki service (domesticated Dokuwiki) –Mailing list service (probably Sympa) –Document storage service (t.b.d.) Goal: Pilot VO Platform in SWITCHaai with basic set of features in Q4 2010 Deployment and adding more SP services in 2011

19. © 2010 SWITCH Summary Membership for a VO is expressed by an attribute VO attributes are aggregated from VO Platform(s) Access control using VO Attributes very easy with Shib VO Attributes are managed on VO Platform More information and demo instructions –http://www.switch.ch/aai/about/vo-concept/http://www.switch.ch/aai/about/vo-concept/ –Email contact: aai@switch.ch 19

20. © 2010 SWITCH 20 Outline Introduction AAI and VO: The SWITCH approach Technical Solution Roadmap and Summary Appendix: Email Enrollment

21. © 2010 SWITCH 21 Step 1: Invitation token sent by email Subject: Join the Swiss Resistance From: VO Group Admin To: William Tell You are invited to join the VO group “SwissResistance”, please click on https://voplatform.example.org/enrol?to ken=324jcxio34529cj https://voplatform.example.org/enrol?to ken=324jcxio34529cj User is invited by VO admin

22. © 2010 SWITCH 22 Step 2: Authentication at user IdP User clicks on invitation link which points to VO Platform administration. This forces the user to authenticate at his IdP

23. © 2010 SWITCH 23 Step 3: Adding Shared ID to data store SP provides user’s Shared ID to VO Platform administration, which stores information in a data store and adds the user to the VO assigned to the invitation token

24. © 2010 SWITCH 24 Step 4: Access of a VO Service User is shown a list of VO Services that are available for this VO. User clicks on a link of one particular service.

25. © 2010 SWITCH 25 Step 5: VO Service authentication with SSO VO Service SP forces user to authenticate. Due to SSO this may not be noticed by user. SP receives user’s attributes and Shared ID from User IdP

26. © 2010 SWITCH 26 Step 6: Attribute aggregation SP uses Shared ID of user to query VO Platform with a standard SAML attribute query and receives user’s VO attributes

27. © 2010 SWITCH 27 Step 7: SP delivers aggregated attributes SP provides user’s attributes from User IdP and from VO AA to application