SWITCH AAI Info Day 21 March 2006, Zurich

Ueli Kienholz (from SWITCH) running the day.

Introductions

Christoph Graf

We all gave brief introductions about ourselves, chaired by Ueli.

From the UK, there was Mike Jones (University of Manchester) representing the SHEBANGS project, David Spence, representing the ShibGrid project and (me) Mark Norman, representing ESP-GRID and (partly) ShibGrid.

Christoph Witzig joined us - he's team leader of middleware. The main grid person at SWITCH, really (was there at the Grid and Shib BOF at GGF).

Ueli at SWITCH for 4.5 years. Involved in Shib project in Switz since beginning. Now mostly concerned with deployment and increasing the user base in Switz.

Ueli general presentation on Shibboleth

Project timeline

Started in 1999 - came up with term AAI. For e-learning courses.

In the beginning it was mainly top-down, encouraging managers and institutions, then they did a study, looking at which tools were out there.

Looked at Shibboleth and PAPI (from Spain) and also ?TEQUILA? (from Switzerland). Decided on Shib and ran a pilot throughout 2002-03.

Implementation in 2004. In Autumn 2005 all major Universities etc. Now looking at grid and accounting (going into the study, and then pilot phases there).

SWITCHaai building blocks

Includes, IdPs, Central Services, Funding, SPs etc. etc.

The IdP map of Switzerland: main cantonal universities. 2 out of 10 are still missing (to date), but will come on line in the next 2 months. 10 main Cantonal Universities, but another set of HE institutions (some of which are already on-line). Also Univ. Hospital of Zurich, now there. >70% of users in Swiss HE served at present.

At the IdP side:

AuthN systems:

Quite a few SPs. SWITCH have shibbolized quite a few platforms (some done by the Universities)

Trying to promote use in libraries and in commercial sector.

SWITCH have a "jump-start" service: small organisations. SWITCH sets up and runs the Shib server and hands it over to the institution when they are ready.

Christoph Witzig (grid and shib)

Shib concepts: based on SAML etc.

Contrast this with current statement on EGEE (grid)

Christoph showed a really nice slide about trust across EGEE (CA, VOs etc. etc.)

gLite, part of EGEE-2 proposal (by SWITCH in the EGEE NREN Federation)

Phase 1 (Introductory)

Site Integrated Credential Service (AKA SLIC - short-lived Credential Service)

Phase 1b

Give Shib user access to the grid - you should enable a Grid user access to Shib resources.

This is where the VHO comes in.

Phase 2 (Introductory)

VOMS server interfaces with local home org AA.

Going to do this this summer (work between SWITCH and the Italian VOMS developers at INFN).

SAML Support at the resource (phase 3 - the main body of work)

Goal: Support for SAML for authn and authZ without relying on X.509 (on a configurable basis)

Should be based on SAML2

Policy questions for phase 1

Q: What sort of policy should be formulated for the certificates generted out of SWITCHaai?

Minimum requirements for:

SLCS

Traditional user certificates

Several SLCS (but thinking about one SCLS per country too)

one CA per country

Automated generation based on user management system

"Traditional" RA (e.g. photo ID)

Lifetime <1mio sec

Lifetime < 1year+1month

Revocation handling optional

Revocation handling mandatory

Ended up coming up with the question of why have two types of certificate (if they're going to end up so similar), so now they're looking into generating proper X.509 certificates using Shib front end.

Needs strong authentication to justify this process.

Ueli presentation re-started

Virtual Home Organisation (VHO)

http://www.switch.ch/aai/vho/

Has been implemented and is very successful. About 15,000 users to date. (1,500 very active).

@VHO "AAI-enabled" accounts for users who do not have an Identity Provider.

Have about 11 different VHOs. One for each SP that needs identities.

SWITCH runs the policies for establishing etc. the VHOs.

User contacts the SP, then the SP provides a web interface for the user to add themselves (with permission) to the VHO.

Kind of strange that they chose to not have one central VHO (even though all 11 VHOs are actually in the same LDAP, the user could potentially be wanting to use >1 SPs and therefore would be in >1 VHO and the user would therefore have >1 username/password combinations).

SP example scenario: DOIT

"Dermatology Online with Interactive Technology"

Typically a resource might want to have x users from one University, y from another, z from the VHO etc.

Portal example

Not really a web portal, more an AuthN gateway. Used mostly for access to WebCT instances.

Shibboleth in front of AAIportal.

Portal used to really enable AuthN, rather than contain applications/SPs as portlets. Once 'logged in' the user talks directly to the application (WebCT).

SWITCH Organisational Framework

SWITCH acts as SWITCHaai Federation Service Provider. Federation membership based on signed service agreements.

The Advisory Committee and Operations Comm. cross over between Federation Members and the SWITCH service provider itself.

Federation partners: now have contract with Elsevier. Such partners cannot provide an IdP - only services. SPs are originally nominated by a University and then gets a contract with SWITCH.

Torbjorn (from Sweden) said that the federations that they had there and were planning were not just Shibboleth federations as they are more like national agreements and groups. So there is a blurring of trust (i.e. identifying each other) and authZ.

Upgrading at IdPs

Migration plan

Mid summer 2005. Upgrade from 1.2 (and maybe 1.1) to 1.3.

Attributes

Attributes that they ask for at SWITCH (about 20):

Personal (unique ID, Surname, Given name)

Group Membership (Home org name, home org type, affiliation)

These are based on eduPerson Attributes. SWITCH doesn't use any of the eduPerson "scoped" attributes as they are a bit dodgy at the moment.

SWITCH has an Attribute Viewer:

Data Protection Issues

The IdP may restrict the data release as strict as they see fit (the site ARP).

Now SWITCH has a Resource Registry so that SWITCH can list the attributes requested and sent to the SPs. Must be approved by the Resource Registry Administrators of the SP and of the IdP.

SWITCH has a metadata file (kept centrally at the federation level) that defines all IdPs and SPs. However, they see this as a scalability problem as the one file will become megabytes in size and get updated a lot (as SPs are added).

They are therefore considering using the MAMS-like system of having one SP description XML file per SP held at the federation level.

ARP for users

SWITCH have an interface. Potentially (unless users turn it off) they will be prompted that "this resource is asking for the following attributes... Is this OK?"

This interface will be used at the central VHO from next week. And then released as an additional part to the IdPs in the future.

e.g. Elsevier only needs to know the Organisation name (they don't ask for IDs or email addresses).

[We were joined by Valéry Tschopp - a guy who is part of the main AAI team and with a bit more knowledge of grids].

What next for SWITCH?

A strategy for the federation, marketing, information (web site, mailing lists, events), support, consulting, training, international contacts, Providing Federation-Metadata and Configuration Guides.

Operating:

Activity portfolio for the SWITCHaai team

Funding

New cooperation projects (2004-2007)

Focus of activities:

Further information

Web site

Shibboleth Demo

Course materials for training SPs (which SWITCH does):

Talking grids etc. with Valéry Tschopp

Mike asked how easy is it for AA to interface with VOMS (to supply SAML assertions to VOMS to support VOs).

Then we went and talked about SHEBANGS and ShibGrid.

Lessons learned and problems

Key success factors:

Problems experienced:

ESPGRIDwiki: SWITCH_March_06 (last edited 2013-05-17 16:26:48 by localhost)