AAI-enabled VO Platform“VO without Tears”

Christoph Witzigchristoph.witzig@switch.ch

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: aai@switch.ch

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