Virtual Organizations A New Implementation Approach Using SAML Attribute Aggregation

Lukas Hämmerle [email protected] TNC 2010, 1. June 2010 Dienstag, 1. Juni 2010

What are Virtual Organisations?

Definition: “A Virtual Organisation (VO) is a group of individuals collaborating through the use of online services” (VO = People + Services) Chad la Joie

Example VO individuals: • Group of researchers in a research project • Students working on a semester project • Lecturers working on new e-learning content

© 2010 SWITCH Dienstag, 1. Juni 2010

2

VOs in the context of Middleware

Uni Z

Uni Y

FH X

Assumptions: • Individuals are from different organisations • Individuals have an Authentication and Authorization Infrastructure (AAI) • AAI is assumed to be SAML2-based © 2010 SWITCH Dienstag, 1. Juni 2010

3

What do Virtual Organisations need? 1. VO Services • In order to facilitate collaboration, online tools are required. E.g. Wikis, mailing lists, document storage, calendars, … 2. Authentication • In order to access the tools, users must be identified 3. Authorization/Access control • Only members of a VO should be allowed to access certain content or functionalities

© 2010 SWITCH Dienstag, 1. Juni 2010

4

Which needs have to be addressed? 1. VO Services • Many services are already AAI-enabled 2. Authentication • AAI already provides authentication • Many applications already support AAI 3. Authorization/Access control • How can this be solved?

© 2010 SWITCH Dienstag, 1. Juni 2010

5

Scenario where authorization is easy Authorization for larger groups like a VO is manageable for users that share common attribute values IdP Z

IdP X

IdP Y

SP

© 2010 SWITCH Dienstag, 1. Juni 2010

Medicine students Other users

AuthType Shibboleth ShibRequireSession On ShibRequireAll require homeOrg idpX.ch idpY.ch idpZ.ch require affiliation student require studyBranch medicine 6

More common authorization scenario VO members never share a common attribute ➟ That’s a challenge

IdP Z

IdP X

IdP Y

SP © 2010 SWITCH Dienstag, 1. Juni 2010

7

Approach for authorization in VOs Idea: Members of a VO are given a common attribute. This (VO) attribute represents membership in a VO.

VO2 VO1 VO3

AuthType Shibboleth ShibRequireSession On require isMemberOf VO2

© 2010 SWITCH Dienstag, 1. Juni 2010

VO Attribute: isMemberOf=VO1 isMemberOf=VO1;VO2;VO3 isMemberOf=VO2 isMemberOf=VO1;VO3 8

The problem of setting attributes Problem: • Home Organisations are responsible for data they assert • They don’t set VO Attributes on request! ➟ Infeasible to set VO attributes at Home Organisations

© 2010 SWITCH Dienstag, 1. Juni 2010

9

If Home Organisations don’t set attributes... ... let attributes be set somewhere else. Solution: • Make a 3rd party set VO attributes ➟ VO Platform • Make Service Providers aggregate attributes from VO Platform and user’s Home Organisation

© 2010 SWITCH Dienstag, 1. Juni 2010

10

How the Attribute Aggregation works VO Service Provider aggregates attributes from: Home Organisation

1. User’s Home Organisation Attributes are set by user’s Home Organisation

User IdP

2. VO Platform(s) Attributes are set by VO administrator

Attributes

VO Platform

VO IdP

1.

Attributes

3. 2.

VO Service

SP

➟

Application

SP receives aggregated set of attributes © 2010 SWITCH

Dienstag, 1. Juni 2010

11

The involved components • Home Organisation:

Home Organisation

Authenticates user and asserts basic identity information

User IdP

SP SP

Application Application

SP

Application VO Service

• Virtual Organization Services:

Used by VO members in order to perform their work. Could be wikis, calendars, etc.

VO Platform SP

VO GUI

• Virtual Organization Platform: Platform Logic

DB

IdP AA

... VO1

VO2

© 2010 SWITCH Dienstag, 1. Juni 2010

Set of software to manage VOs and their members. Interacts with Virtual Organization Services.

VON

12

User identification at involved components • All components must know user by a common identifier: the Shared ID • Value of Shared ID is used in SAML 2 Name Identifier of attribute request for attribute aggregation.

• Option 1: Use value of eduPersonPrincipalName, mail or similar • Problematic for user privacy due to data correlation attacks

• Option 2: Use value of affiliation-targeted persistentID • Generated by the IdP based on Affiliation role descriptor in metadata • Same user has different Shared IDs in different VOs

© 2010 SWITCH Dienstag, 1. Juni 2010

13

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

© 2010 SWITCH Dienstag, 1. Juni 2010

14

Step 1: Invitation token sent by email Subject: Join the Swiss Resistance From: VO Group Admin To: William Tell

User is invited by VO admin

You are invited to join the VO group “SwissResistance”, please click on https://voplatform.example.org/enrol? token=324jcxio34529cj

Home Organisation

User IdP

VO Platform

SP

Administration Data Store

IdP AA SP

Application VO Service

SwissResistance

© 2010 SWITCH Dienstag, 1. Juni 2010

OtherGroup

15

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

Home Organisation

User IdP

VO Platform

SP

Administration Data Store

IdP AA SP

Application VO Service

SwissResistance

© 2010 SWITCH Dienstag, 1. Juni 2010

OtherGroup

16

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

Home Organisation

User IdP

VO Platform

SP

Administration Data Store

IdP AA SP

Application VO Service

SwissResistance

© 2010 SWITCH Dienstag, 1. Juni 2010

OtherGroup

17

Step 4: Access of a VO Service

Home Organisation

User is shown a list of VO Services that are available for this VO. User clicks on a link of one particular service.

User IdP

VO Platform

SP

Administration Data Store

IdP AA SP

Application VO Service

SwissResistance

© 2010 SWITCH Dienstag, 1. Juni 2010

OtherGroup

18

Step 5: VO Service authentication with SSO

Home Organisation

User IdP

VO Platform

SP

Administration Data Store

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

IdP AA SP

Application VO Service

SwissResistance

© 2010 SWITCH Dienstag, 1. Juni 2010

OtherGroup

19

Step 6: Attribute aggregation

Home Organisation

User IdP

VO Platform

SP

Administration Data Store

SP uses Shared ID of user to query VO Platform with a standard SAML attribute query and receives user’s VO attributes

IdP AA SP

Application VO Service

SwissResistance

© 2010 SWITCH Dienstag, 1. Juni 2010

OtherGroup

20

Step 7: SP delivers aggregated attributes

Home Organisation

User IdP

VO Platform

SP

Administration Data Store

SP provides user’s attributes from User IdP and from VO AA to application

IdP AA SP

Application VO Service

SwissResistance

© 2010 SWITCH Dienstag, 1. Juni 2010

OtherGroup

21

Attributes and their origins at VO Service Home Organisation

User IdP

uid=w.tell givenName=William surname=Tell ... Shared ID (persistentID): IdP!SP!Type-4-UUID VO Platform

SP

VO Management

VO Service

SP

Application

uid=w.tell givenName=William surname=Tell ... isMemberOf=VO:SwissResistance isMemberOf=VO:FreeSwitzerland

DB

IdP AA

SwissResistance

FreeSwitzerland

isMemberOf=VO:SwissResistance isMemberOf=VO:FreeSwitzerland © 2010 SWITCH Dienstag, 1. Juni 2010

22

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 Dienstag, 1. Juni 2010

23

VO implementation requirements •VO Service SP: –Option 1 (e.g. ePPN as Shared ID): Shibboleth 2.2 or newer –Option 2 (persistentID as Shared ID): Shibboleth 2.3 or newer

• Home Organisation User IdP: –Option 1: Any existing user IdP (including Simple SAML PHP) –Option 2: Shibboleth 2.2 or newer

•VO Platform IdP: –Shibboleth 2.0 or newer: Attribute queries must be supported

•VO Platform User Registration/Administration –GUI is likely to be very specific for each instance of a VO Platform

© 2010 SWITCH Dienstag, 1. Juni 2010

24

Status and future developments • Proof-of-concept using SWITCH Group Management Tool as temporary VO administration GUI • Was also tested in inter-federation setup • VO Platform is currently implemented by SWITCH –Ideas and partial implementation by Chad la Joie (itumi)

• 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 beginning of Q4 2010 © 2010 SWITCH Dienstag, 1. Juni 2010

25

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/ © 2010 SWITCH Dienstag, 1. Juni 2010

26