1 / 27

AAI-enabled VO Platform

AAI-enabled VO Platform. “VO without Tears”. Christoph Witzig christoph.witzig@switch.ch. EGI TF, Amsterdam, Sept 15, 2010. Outline. Introduction AAI and VO: The SWITCH approach Technical Solution Roadmap and Summary Appendix: Email Enrollment. SWITCHaai Federation in Spring 2010.

braden
Télécharger la présentation

AAI-enabled VO Platform

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. Access to AAI Resources 3

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

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

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

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

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

  10. AAI and VO: SWITCH Approach (2/2) SP aggregates attributes: • From user’s Home OrganisationAttributes are set by IdP admin • From VO Platform(s)Attributes are set by VO adminUser is identified by an attribute thatis used as shared ID • Augmented set of attributes available at VO SP

  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. Outline • Introduction • AAI and VO: The SWITCH approach • Technical Solution • Roadmap and Summary • Appendix: Email Enrollment

  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. Architecture Overview

  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. 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. Outline • Introduction • AAI and VO: The SWITCH approach • Technical Solution • Roadmap and Summary • Appendix: Email Enrollment

  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. 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/ • Email contact: aai@switch.ch

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

  21. 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?token=324jcxio34529cj Step 1: Invitation token sent by email User is invited by VO admin

  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. 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. 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. 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. 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. Step 7: SP delivers aggregated attributes SP provides user’s attributes from User IdP and from VO AA to application

More Related