SWITCH AAI Info Day 21 March 2006, Zurich

Ueli Kienholz (from SWITCH) running the day.

Introductions

Christoph Graf

• Working for SWITCH a long time (first in 1991). Created AAI in 1999. Heads security department of SWITCH - AAI is big thing

• Torbjörn Wiberg
  • Chief Information officer at Umeå University in Sweden. Interested in AAI for high performance computing. Building an identity federation in Sweden.

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:

• Shib server, running on Tomcat.

AuthN systems:

• OpenLDAP with CAS or Pubcookie
• Kerberos Authn with Active Directory
• Windows authn with IIS

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.

• User has one !IdP and one authN method
• trust between !IdP and SP
• 2-tier architecture. Delegation isn't really a part of Shibboleth.

Contrast this with current statement on EGEE (grid)

• gets a long-term cert once per year
• gets proxy cert from VOMS (1 VOMS server per VO)
• attributes in proxy cert (this tends to be called a "temp. cert") is really "member of group" (cannot have different status levels within these)
• delegation possiblem - SP calls myProxy server to get further proxy certificates.

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)

• SWITCH tried not to replace certificates, but wanted interop. between Shibboleth and PKI.
• Not trying to add to Globus, just gLite
• Home institution should be the !IdP
• Home institution provides some attributes
• VOs are needed for grid-specific attributes

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

• supports ECP Profile (constrained delegation)
• will be used in Shibboleth 2 (or maybe 2.1...) (e.g. resource broker wanting to send a job on in the name of that user).

Policy questions for phase 1

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

Minimum requirements for:

• SLCS certificates: TAGPMA (recently adopted)
  • (so that user can use some sort of cert on grid)
• traditional certificates

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.

• It appears that SWITCH is thinking along the same lines as JISC/UK (or maybe it's the UK that is thinking like SWITCH!).

Upgrading at IdPs

Migration plan

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

• SWITCH wrote guides for IdPs as to how to do this. Really impressive!

Attributes

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

• http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf

Personal (unique ID, Surname, Given name)

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

• Have reserved "Organizational Path" and "Organizational Unit Path" for if further attributes need to be looked up at a remote LDAP.

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:

• get a friendly interface of all your attributes
• get a HTTP variable set (same thing in HTTP terms) but looks more complex to the average user
• all users can access this to see which attributes they have

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.

• end up with a Proposed Addition to the site.ARP
• IdP may decide to accept this
• the site.ARP is an XML file containing all of the SPs that the IdP can do business with and which attributes each SP wants

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:

• WAYF
  • WAYF is distributed (or redundant) - there's another instance at Univ. of Lucerne
• VHO
• Resource Registry

• Test counterparts (IdPs and SPs)

  • To allow the universities to test against etc.
• Jump start service
  • SWITCH operates an IdP for orgs who do not yet have the resources to do so on their own (and then the org could take control later).

Activity portfolio for the SWITCHaai team

• Interoperation
  • Attribute spec to metadata etc. etc.
• Organisational framework
  • Federation partners, committees, design/marketing etc.
• Service Providers (resources)
  • Universities holding resources, AAIportal, grid, other browser apps., other non-browser apps. AAAI (accounting - exchange of credit points between universities. Little progress in this - it needs more high level input).
• Funding
  • For project management and support of projects
• Identity Providers
  • Support of Universities, the VHO, Jump start service,
• Central Services
  • WAYF, test lab, resource registry, operations, training support etc.

Funding

New cooperation projects (2004-2007)

• Projects defined and started in 2005.

Focus of activities:

• SWITCH have designated 2006 as the "year of the libraries".
  • have already got Elsevier on-line in the federation
  • also ?EZproxy?
• Edugain
• non-browser applications (once Shib 2.0 arrives)

Further information

Web site

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

Shibboleth Demo

• http://www.switch.ch/aai/demo

Course materials for training SPs (which SWITCH does):

• http://www.switch.ch/aai/events/archive.html

  Click on slides in the section AAI pour les applications web (AAI resource workshop) - Mai 2005 (the resources are in English and in PDF format).

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

• Valéry is working on a 2 year project beginning March this year.

  GridShib has done proof of concept - it's been done. SWITCH trying to do a proper integration in their environment. Want to get their output in VOMS code and then for it to be included in gLite. (Project is funded by EGEE).

Then we went and talked about SHEBANGS and ShibGrid.

• Ueli drew a good diagram!

Lessons learned and problems

Key success factors:

• relationships trust SWITCH->universities

• community infovement
• good resources community and funding
• capable people
• Subsidies from federal gov.t helped: gave credibility and guaranteed involvement of the University management
• Bottom up approach as well as that top down
• Try to keep support excellent to the universities
• the VHO

Problems experienced:

• IdPs not having integrated user directories

• Persuasion: had to reach a critical mass of involvement (chicken and egg)
• Sustaining momentum in the project
• Server certificate issues: configuration etc. 80% of all hard to diagnose problems early on seemed to come back to the certificates.

• Firewall issues - bizarrely, some IdPs blocking some ports

• Shibbolization of new resources (that haven't been seen before)
• Conceptual - allowing access to the homeless (resolved by VHO)
• Conceptual - groups
• User acceptance: too many clicks (pop-ups, WAYF) untrusted certificates
• Co-operation: control of code development - feeding back to Shib/Internet2. Code will only be acceptable if it is of very general/core purpose (for good reason).

• Deployment - Need to build local know-how (not enough to go in and do it for IdPs - need to get them to know how to maintain things).

• Conceptual: attributes requested by resource not necessarily available from IdP