This is a work plan for GÉANT3 Identity Federations.

Participants

Available resources include:

• NorduNet Nordic 4.4 (15.8 MM)
  • UNINETT 3.3 (9.9 MM)
  • Wayf.dk 0.8 (2.4 MM) Pending...
  • NorduNet 0.3 (0.9 MM) OK.
  • SUNET (2.0 MM) Moonshot.
• DFN Germany 3.6 (13.0 MM) Pending...
• SURFnet Netherlands 3.0 (10.8 MM) Partly confirmed. Pending...
• JANET UK (6.0 MM) OK. Moonshot.
• Terena Netherlands 1.4 (5.0 MM) OK, confirmed.
• CARNET/SRCE Croatia 1.2 (4.3 MM) OK. Awaiting confirmation.
• RENATER France 0.8 (2.9 MM) Pending...
• CESnet Chezch 0.4 (1.4 + 5.0 MM) Pending...
• NIIF Hungary 0.4 (1.4 MM) Pending...
• PIONIER Polen 0.4 (1.4 MM) OK, confirmed.
• SWITCH Switzerland 0.4 (1.4 MM) OK, confirmed.
• RedIRIS Spain 0.4 (1.4 MM + 3 MM) OK, confirmed.
• RESTENA Luxembourg (0.6 MM) Moonshot?

Total of 16FTE. Approx 30% of this will be...

• $Id: gn3-switchvo-idp.txt 311 2010-02-24 10:56:35Z andreas $
• Author: Lukas Hämmerle, SWITCH

This document describes how to configure a Shibboleth Identity Provider to be used as Virtual Organization Platform Identity Provider.

Setup

It is assumed the Shibboleth Identity Provider is fully deployed and that there is a MySQL? database on the same host as the IdP? (this is not required but will be assumed in the examples below). It might be necessary to install the jdbc drivers manually so that the Identity Provider can use them.

Prerequisites

It is assumed that there is a MySQL? database called "gmt" and therein a table called "GroupMembers". This table should contain at least the colums "uniqueID" and "group". A MySQL? user "gmtUser" identified by password "12345678" should have access to this t...

• $Id: gn3-switchvo-sp.txt 311 2010-02-24 10:56:35Z andreas $
• Author: Lukas Hämmerle, SWITCH

This document describes how to configure a Shibboleth Service Provider to be used as Virtual Organization Service Provider. In short, Simple(Attribute)Aggregation has to be configured.

Setup

It is assumed that there is a VO Platform consisting of a Shibboleth Identity Provider, an attribute storage (e.g. a database or LDAP server) and a VO administration interface (e.g. SWITCH Group Management Tool, Grouper, etc) to manage the membership of VO users.

Prerequisites

It is assumed that you have a fully working Shibboleth Service Provider configured for one or more federations. Configuring VO support while the Service Provider is not yet working in general, is not a good idea.

General procedure

Make sur...

Relevant plan documents:

• Year 1 Work plan
• Revision history of this document

Aim of the JRA3 Identity Federation Task

Identity Federations, or simply Federations, are bas...

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

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

• $Id: metadata-aggregation-requirements.txt 366 2010-07-14 06:31:56Z lhaemmerle $

assumption: metadata is as defined in http://www.oasis-open.org/committees/download.php/35391/sstc-saml-metadata-errata-2.0-wd-04-diff.pdf

Disclaimer

This document is work in progress and may change without notice. Therefore, do not yet rely on it!

Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119][].

Document Structure

The goal of this document is to define and list the requirements that shall be implemented by a Metadata Aggregator implementation. The implementation of a Metada Aggregator is likely to be used also outside of eduGAIN in national federations. Therefore the implementation requirements are not focused only on the usage inside eduGAIN. The document also ...

• $Id: gn3-usercentric-technologies.txt 179 2009-11-12 11:11:41Z andreas $
• Author: Licia Florio florio@terena.org

Introduction

Managing authentication and authorisation mechanisms is quite a complex task. In the academic community this task becomes particularly challenging as researchers, lecturers and students often move between institutions and departments and collaborative projects require users to share their resources. These changes not only affect the individuals concerned, but also their roles within the institutions, which have to be taken into account. It is therefore important to be able to keep track of, and handle the changes that continuously take place.

The mapping of users to electronic identities is a strategic element in any organisation, since it constitutes the basis for the access to institutional data and IT services. This process is known as Identity Management.

In recent years...