aai-enabled vo platform
DESCRIPTION
AAI-enabled VO Platform. “VO without Tears”. Christoph Witzig [email protected]. 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. - PowerPoint PPT PresentationTRANSCRIPT
AAI-enabled VO Platform“VO without Tears”
Christoph [email protected]
EGI TF, Amsterdam, Sept 15, 2010
© 2010 SWITCH 2
Outline
• Introduction
• AAI and VO: The SWITCH approach
• Technical Solution
• Roadmap and Summary
• Appendix: Email Enrollment
© 2010 SWITCH 3
SWITCHaai Federation in Spring 2010
# AAI enabled accounts# Resources
# Home Organizations
>96% coverage inhigher education
© 2010 SWITCH
Access to AAI Resources
3
© 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
© 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
© 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
© 2010 SWITCH 8
Outline
• Introduction
• AAI and VO: The SWITCH approach
• Technical Solution
• Roadmap and Summary
• Appendix: Email Enrollment
© 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
© 2010 SWITCH 10
AAI and VO: SWITCH Approach (2/2)
SP aggregates attributes:
1. From user’s Home OrganisationAttributes are set by IdP admin
2. 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
© 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.
© 2010 SWITCH 12
Outline
• Introduction
• AAI and VO: The SWITCH approach
• Technical Solution
• Roadmap and Summary
• Appendix: Email Enrollment
© 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
© 2010 SWITCH 14
Architecture Overview
© 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
© 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
© 2010 SWITCH 17
Outline
• Introduction
• AAI and VO: The SWITCH approach
• Technical Solution
• Roadmap and Summary
• Appendix: Email Enrollment
© 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
© 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/– Email contact: [email protected]
19
© 2010 SWITCH 20
Outline
• Introduction
• AAI and VO: The SWITCH approach
• Technical Solution
• Roadmap and Summary
• Appendix: Email Enrollment
© 2010 SWITCH 21
Step 1: Invitation token sent by emailSubject: Join the Swiss ResistanceFrom: VO Group AdminTo: William Tell
You are invited to join the VO group “SwissResistance”, please click on https://voplatform.example.org/enrol?token=324jcxio34529cj
User is invited by VO admin
© 2010 SWITCH 22
Step 2: Authentication at user IdP
User clicks on invitation link which pointsto VO Platform administration. This forcesthe user to authenticate at his IdP
© 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
© 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.
© 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
© 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
© 2010 SWITCH 27
Step 7: SP delivers aggregated attributes
SP provides user’s attributes from User IdP and from VO AA to application