Oxford Shibboleth Projects Meeting: 21 Jun 2006

To explore areas of useful collaboration and coordination between Sakai-VRE-demo, ShibGrid, SPIE and maybe other Shibboleth-using projects, and some related technical issues.

These notes based on minutes from the 21 Jun 2006 meeting, with subsequent clarifications.



1. Agenda/review aganda

  1. Review agenda (All) - no change
  2. Brief summary of projects' goals and status w.r.t. Shibboleth (All)
  3. Shibboleth attribute passing models (Christian)
  4. Using multiple federations for a single service (Christian)
  5. Explore prospects for a shared IdP deployment for all Oxford projects (All)
  6. Hardware/software platform options (All)
    • (performance, machine room space, virtualization)
  7. Long-term maintenance and sustainability issues for common system(s) (All)

2. Brief summary of projects' goals and status w.r.t. Shibboleth

GK/SY: Sakai-VRE multi-site, using Shibboleth federation of authentication. Not primarily a development project. Other non-Shibboleth project work relates to other issues such as searching, which raises issues of access to user metadata provided by or keyed by Shibboleth-supplied attributes.

Current state is that we have Shibboleth IdP and AA installed and linked to OUCS WebAuth and LDAP systems, and have an SP module controlling access to static Apache server content. We are just starting to look at how to get Sakai to perform access control decisions and key personalization information based on Shibboleth authentication.

KT: ShibGrid, integrate NGS into academic framework, using Shibboleth to supply authentication details. NGS currently needs e-science (X.509) certificate: proxy credentials are stored on MyProxy server and delegated to the NGS portal. With Shibboleth, the MyProxy built-in CA can generate short-term limited-rights certs for users who don't have eScience cert, and delegate to the grid portal, so that portal can access other services/resource on behalf of NGS users. Some appropriate policy should be followed to decide whether a certificate can be issued for a user based on that user's non-eScience authentication or attributes.

Attributes: scoped User-ID, as account name for MyProxy server. Not yet sure what per-user attributes will be required.

Started project 2 months ago. Have own copy of Shibboleth installed and running, and now looking to get attributes into NGS portal (StringBeans based, installs on Tomcat).

CF: SPIE project - integrating institutional applications with Shibboleth; Bristol looks at external component integration using WSRP. Project nearly finished. Have created software JAAS (Java Authentication and Authorization Service) module for use with Shibboleth, which pulls all Shibboleth attributes into JAAS structure. Also from Bristol, a WSRP module, and "remote profiling" of personal profiles created by portals, for remote storage of personalization information. Some project goals could not be fully accomplished because of delays in availability of SAML "constrained delegation" profiles for use with/in Shibboleth. Web interface (servlet) to change attribute release policies for users - this hooks into LDAP to find what attributes are available.

Also created: examples using PERMIS for authorization using Shibboleth attributes, but sitting on top of the Shibboleth attribute resolver. Web based (servlet) editor for PERMIS policies. Web service interface to allow changing attributes and release policy by an application running under service provider control. For the most part, these are stand-alone components that can be used with any servlet system. Also have a SPIE federation WAYF.

Also have a SPIE IdP system running in the OUCS machine room.

3. Shibboleth attribute passing models

Or: getting attributes into portals.

We have a set of attributes from Shibboleth in HTTP headers coming into a portal: how to we get them into the infrastructure of the Portal. JAAS module (SPIE project) gets its attributes from the SAML assertion header "export-assertion" in Apache config; header field name 'Shib-Attributes'), and created a JAAS module that is used by the application server. The exact mechanisms for getting information to a servlet depends on the application server; application server configuration can be used to base access control on attributes. Attributes may be made available to Servlets via the servlet container interface - this is the only standardized mechanism. Other non-standard mechanisms may also be used.

4. Using multiple federations for a single service

A single application can be accessed via multiple federations. An IdP and/or SP can be in multiple federations. Choice of federation is determined by the WAYF service the request is redirected to -- user may be offered a choice prior to WAYF redirection.

Alternatively, use different access URIs for different federations. Look for mappings in Shibboleth.xml (SP configuration).

5. Explore shared IdP deployment for Oxford projects

The focus on shared infrastructure is the Shibboleth IdP (including AA) components. The SP modules are necessarily tied to the application platform which is using Shibboleth authentication.

Different WAYFs for different federations; currently typically 1 WAYF per federation, but WAYFs can be replicated. Future developments are likely to move the WAYF logic into the SPs, using the federation metadata.

Each SP and IdP must refresh its local copy of federation metadata from a central source for the federation. This allows for members joining and leaving, and other configuration changes.

5.1. A "thought experiment"

Let us assume a single IdP for Oxford:

A new project requires to use the IdP:

to the application).

already recognized by the new federation, then send a joining request and update local IdP configuration. Otherwise, may need new key/certificate for the new federation. The new federation may impose some particular requirements on the IdP configuration (IdP.xml).

6. Hardware/software platform options

(performance, machine room space, virtualization)

A high-power machine is not necessarily required; but in the longer term, expect shib credentials to take longer to issue than kerberos (by order of magnitude), and likely to be re-requested on a comparable frequency (once per browser session).

SPIE platform: Intel 2.5GHz, 2Gb, RAID array, Debian, JBoss, Tomcat, Java 1.5, in OUCS machine room. This machine runs 5 instances of User Mode Linux (UML) - the stable kernel is of unknown provenance.

Sakai: Intel 1GHz, 0.5Gb, simple disk, Scientific Linux 4.2, Tomcat 5.5-16, Java 1.5, in OUCS machine room

Kang: (currently on laptop, will move to SPIE IdP)

Concerns expressed about platform security, vis-a-vis automatic updates, etc. Debian has a good update service comparable with Scientific Linux, so that should be OK. The unknown provenance of the current SPIE platform kernel is a concern.

It's not entirely obvious what platform should be used for a common IdP service:

should be on dedicated hardware or a virtualized system, though we prefer a virtualized system if a suitably stable software combination can be identified.

7. Long-term maintenance and sustainability issues for common system(s)

Once configured, an IdP system should be reasonably low (but non-zero) maintenance in day-to-day use. The main maintenance workload is likely to be new federation memberships. We really want it to run on a platform that will itself be low-maintenance as far as security and stability updates are concerned. This means one that is, as far as possible, a standard, widely-used configuration.

Xen may be a better choice than UML for virtualization.

NSMS (OUCS) virtualization is unsuitable for current development purposes, due to lack of root access, and cost of firewall configuration change costs, among others.

8. Summary of actions and/or proposals agreed

[All] need to think about a plan for creating a production quality (in terms of stability and security, not necessarily performance) IdP deployment for shared use.

[Someone, TBD] look into virtualization options for Linux systems.

9. References

10. Terminology

refers to a Shibboleth identity provider, whose primary role is to determine the identity of a web user, and create an testable assertion (in SAML) about their authenticated identity and associated attributes. Authentication may be performed by some back-end service, such as webAuth.
is part of the Shibboleth IdP function, and collects attributes about an authenticated user into a SAML assertion about the authentciated user. Attributes may be obtained from a back-end service, such as LDAP.
is a Shibboleth Service provider module, which intercepts selected web access requests, redirects them to an IdP (possibly via WAYF), and passes the request to its original service destination only when a suitable authentication and attribute assertion has been constructed.
is a "Where Are You From" service that routes a request for authentication to a suitable IdP server, often (but not necessarily) by presenting a Web Form asking the user to indicate their home institution.

-- GrahamKlyne 2006-06-26 10:54:20

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.