• $Id: gn3-vo-testinggmt.txt 189 2010-01-13 10:21:52Z andreas $
• Author: Lukas Hämmerle, SWITCH, lukas.haemmerle@switch.ch

1 Goal

The goal was to find out if and to which extent the PoC would technically work in an interfederation environment with different implementations of SPs and IdPs.

Another point that we wanted to check was whether the PoC could also handle other attributes like the eduPersonPrincipalName instead of the swissEduPersonUnique attribute (only used in Switzerland) as shared identifier for the attribute query to the VO platform.

As described below, using eduPersonPrincipalName/swissEduPersonUnique/email as sharedID is only an intermediate step because the end goal should be to use the eduPersonTargetedID, which cannot yet be used as of today because there is one feature missing required for this.

Any usability, organizational and legal issues weren't covered in these tests.

2 Introduction

Short description, slides and demo instructions can be found here:

• VO using simple attribute aggregation concept description

Basic test setup:

• VO Platform
  • Shibboleth 2.1.x IdP + MySQL database + GMT 1.3
  • AAI Test federation
  • How to configure Shib IdP in a VO environment
  • GMT Website
• VO SP
  • Shibboleth SP 2.2.x
  • AAI Test federation
  • How to configure Shib SP in a VO environment
• IdP with test accounts
  • Shibboleth 1.3.x and Shibboleth 2.x,
  • AAI Test federation

3 How we tested:

All involved components knew each other via metadata. Either by manually adding metadata files of the other components to an IdPs or SPs configuration or by making sure there were entries in the JRA3 T2 metadata aggregation test metadata files found here:

• https://hbe.edugain.bridge.feide.no/simplesaml/module.php/aggregator/?id=edugain&set=saml2

The IdPs were configured to release at least given name, surname, email and eduPersonPrincipalName or swissEduPersonUniqueID to the VO Platform administration and the VO SP(s).

The VO SPs were configured to accept the above attributes plus the entitlement attribute. They also were configured to serve as VO SPs by making them query the VO platform upon access of an authenticated user. Generally, we tested more or less what is shown in the screen cast of the PoC demo.

• VO PoC Demo Screencast

4 What was tested:

The following people volunteered for tests:

• Andreas Solberg (UNINETT)
  • Tests with SimpleSAML IdP OpenIDP.org
• Leif Johansson (NORDUNET)
  • Tests with Shibboleth SP as VO SP
• Roland Hedberg (UMEA University)
  • Tests with new Python implementation of SP serving as VO SP
• Torsten Kersting (DFN)
  • Tests with Shibboleth IdP + SP as VO SP

We tried to connect the above-mentioned PoC components operated by SWITCH to the components operated by the people above. IdPs were used to test whether it was possible to access the VO Platform administration and VO services with accounts from other federations. In particular we tried to use accounts that consist of given name, surname, email and an identifier attribute like the eduPersonPrincipalName. SPs were configured to serve as VO SPs doing an attribute query to the VO Platform upon login.

It then was tested if it was possible to access the VO platform administration with a test account. Then it was tested if it was possible to access a VO SP without being member of a VO group. If this was possible, the account then was added to a VO group and one ore more VO SPs were accessed again to check whether there were any VO attributes available that correspond to the VO group(s) this account is member of. If these attributes were available and the SP and VO IdP log showed no errors the test was considered successful.

5 Test results:

The tests demonstrated that the PoC is also (technically) usable in an inter-federation environment. In order to configure the VO SP that protects the VO administration interface to use an additional attribute as shared ID, only few lines need to be added to the attribute-map.xml of this SP.

In general, we are very happy with this approach and we think it is very promising, at least for a Shibboleth based infrastructure like SWITCHaai. It is simple, uses standard components, is easy to configure and easy to understand. The tests can all be considered as successful and no show stoppers were found.

6 What remains to be done:

The testing cycle should be repeated once the role affiliation descriptor is implemented for the Shibboleth Identity Provider (within next few weeks) and potentially SimpleSAMLphp. This then would allow to use the eduPersonTargetedID be used as shared ID which has some advantages over eduPersonPrincipalName/swissEduPersonUniqeID/email when it comes to data privacy. However, for that to work all IdPs and SPs need to support the affiliation role descriptor.