Project index

Planning index

Project planning meeting - 7 August 2006

Present: Stuart Yeates (SY), Graham Klyne (GK)

Last report: SakaiVre/PlanningProgress/20060721

This report: SakaiVre/PlanningProgress/20060807

Next meeting: Wed, 23 Aug 2006, 09:00. SakaiVre/PlanningProgress/20060823


1. Agenda

2. Activity since last report

The main activities have been concerned with (a) transferring our Sakai installation to a new system, a Xen virtual machine on the SPIE hardware, to which additional memory has been added to meet Sakai's hunger for bits, and (b) investigating the options available for using Shibboleth-conveyed attributes as a basis for access control in a VRE. Stuart has been on leave for a week of this period.

Upcoming priorities will be to complete the migration of our Sakai installation, initiate multi-site deployment of Shibboleth authentication, consider selection of tools to be configured in our Sakai deployment (e.g. consider BVREH requirements), start documenting lessons learned about integrating Shibboleth with Sakai (there are now many), and to restart work on the search work package.

GK will be absent for much of the next period. Near-term priorities for SY include:

2.1. Actions closed or completed


[SY+GK] Arrange luchtime meeting with Adam Marshall to explore any possible relevance of the Gian Xi work to our goals. Done. A brief meeting revealed that there was not really any relevant experience in Oxford to draw upon here. Roughly, Guan Xi is an alternative implementation of Shibboleth with an e-learning bias. Other groups are looking at implementing Guian Xi for Sakai, so it may be that they'll solve the problems we are facing, as long as the Guan Xi SP module is interoperable with the Ineternet2 IdP module. I think there's little to be gained right now in us trying to learn about Guan Xi details, but we should monitor the status of their Sakai work. The person to be in touch with is Alistair Young at UHI. For more background, see and See also further discussion below.


[SY+GK] Arrange meeting with Christian Fernau to further discuss options for combining out Shibbboleth IdP facilities. Done. Using the SPIE IdP should be quite easy for us. Points to consider include:

  • We would need to agree on attributes to be released.
  • SPIE IdP is already part of SDSS federation (among others). Our Sakai SP will also need to be registered with SDSS.
See also new action 20060803.2.

[SY+GK] Explore use of Sakai's authorization framework, to get a better understanding of the way it employs the user, role and permission concepts, and how they may interact with external authentication and authorization. Done - see discussion, and actions 20060721.5 and 20060721.6.


[SY,GK] Explore Sakai architectural documents to look for clues about user/role provider functions ("provider" being the Sakai term for components that link to external information sources). Done - see discussion, and actions 20060721.4 and 20060721.6.


[GK] Revisit Sakai "provider" source code to see if it makes more sense in light of what we now know about Sakai container authentication. Formulate tentative integration plan to be posed as a "could this work?" style of question to the Sakai community. Done. See See also discussion, and actions 20060721.4 and 20060721.5.


[GK] Announce progress on Sakai authentication to project partners, and repeat request for information about Shibboleth and/or institutional authentication/directory deployments, and how to progress a project-wide deployment. Done. See Our plan now will be to coordinate initially with just one partner - CCLRC?


[SY] Survey recent Tetra-ELF mailing list archives to see if there are any overlooked messages there that are helpful to our cause. (See Done. No information useful to us was noted.


[GK/SY] Initiated investigation of how to make Shibboleth attributes available for use in Sakai access controls. Initial investigation of Sakai web site is not very helpful. Investigations are being recorded at SakaiVre/SakaiUserDirectoryProvider. Done - see also discussion and actions 20060721.3, 20060721.4 and 20060721.5.


[SY] Investigate performance problems with our Sakai demo machine. The problem appears to be memory shortage, and the present machine cannot be usefully upgraded, so we're now casting about for a new system, mainly with greater RAM memory capacity or potential capacity. Done - but see new activity 20060803.2.

  • Documented more use-cases for Shibboleth-enabling of Sakai, in the course of discussion with Sakai developers. See (These mmight be transferred to our use-case page in the Wiki - SakaiVre/ShibbolethSakaiUseCases.)

  • Have obtained a new SDSS certificate for the Shibboleth SP component on the new machine.
  • 2.2. Actions progressed


    [SY+GK] Modify and document Sakai configuration to persist user database. (Currently, new users added to Sakai are lost on each restart of the system.) The configuration change seems reallly easy: see This change needs to be applied to Sakai when the new installation is complete (see 20060803.2)

    2.3. New activities and notes

    [GK] Write up things learned about Sakai authentication and authorization structure and the consequent options for integration with Shibboleth.

    [GK+SY] Transfer Sakai installation to a Xen virtual machine on the SPIE system hardware. The new virtual machine is running Debian Linux (a supported kernel is necessary for reliable operation under Xen). The change to Debian is throwing up a few issues of system configuration that we need to work through. We'll keep the old machine running for a while as a Shibboleth test machine. See // and 20060721.2. We have started this migration. Tasks still be be completed include:

    • Install IPTables configuration
    • Install SSSHBlack
    • Install and configure HFS backups
    • Install Postfix
    • Install Logwatch
    • Configure Logwatch messages
    • Configure auto-updater
    • Install and configure Sakai
    • Install and configure Shibboleth SP
    [GK] Contact Alistair Young and advise him that we'd like to take advantage of his Guanxi/Sakai work, providing feedback and further testing to help harden this software.
    [GK] Contact CCLRC partners with a view to creating a bilateral Shibboleth authentication federation between our Sakai sites.

    2.4. Summary of ongoing actions brought forward

    [SY] Analysis of search requirements. (On hold while we focus our efforts on the Shibboleth/Sakai integration.)

    [GK] Port SPIE Shibboleth/WSRP (cf. work by Jasper Tredgold) to Sakai: (Waiting for 20060301.10) Install Shibboleth/WSRP software locally, and convert to work with Sakai. The main remaining unknown is to get Shibboleth attributes into the Sakai portal framework - this has been separated out as a new action 20060619.3. No further progress. The value of WSRP is cast further into doubt by this message from Charles Severance:


    [GK] Initiate process of SDSS federation credentials. Have obtained an SDSS CA certificate, but have not yet joined the SDSS federation. See May be overtaken by events with respect to action 20060721.2 - the current plan is to enroll the new machine as an SDSS SP (using the new certificate obtained), and use the SPIE IdP, which is already enrolled with SDSS.

    [GK/SY] Write Shibboleth configuration document, in particular showing how the various configuration elements and functions are inter-related. Also, note relationship between Shibboleth and Eduperson attribute schema, noting in particular Shibboleth's treatment of attributes as a flat namespace, coupled with their more structured interpretation by Shibboleth-using applications.
    [SY] Investigate OUCS procedures for spinning up new shared trial facilities.

    [SY+GK] Modify and document Sakai configuration to persist user database. (Currently, new users added to Sakai are lost on each restart of the system.) The configuration change seems reallly easy: see This change needs to be applied to Sakai when the new installation is complete (see 20060803.2)

    3. Discussion

    3.1. Interaction with Sakai community

    Prompted by some questions about how we might use the SPIE JAAS module to pass Shibboleth attributes into Sakai, there has been some lively discussion on the sakai-dev mailing list, and many details have becomne clearer. In particular, it seems that the Sakai authorization structure is a poor fit with Shibboleth attribute delivery. Alistair Young has encountered similar issues with his Guanxi development, and is taking the approach of constructing a "pod" of data from Shibboleth assertions, suitable for responding to Sakai authorization queries.

    A copy of the main elements of the discussion on Sakai-dev can be reviewed here:

    This discussion has clarified the scope for interaction between Sakai authentication, Sakai authorization and Shibboleth. Unfortunately, it seems that it is not a simple matter to write Sakai providers that simply answer authentication and access control queries on the basis of available Shibboleth attributes, which is what we were looking for. The reason is that Sakai does not provide access to the incoming request context where the Shibboleth attributes are provided to an application. It seems that Sakai, being primarily responsible for handling incoming HTTP requests, assumes that it has extracted all the useful information, and does not allow that provider components might also need access to the request context.

    3.2. Guanxi (reprise)

    The sakai-dev discussion also served to initiate some off-list discussion with Alistair Young, primary developer of Guanxi. Alistair is working on an approach to Shibboleth-based authorization in Sakai, based in Guanxi's distributed SP design, in which a single Shibboleth SP may serve multiple applications on various hosts by means of guards, which are Tomcat request filters that inspect requests to the applications to be Shibbolized. These guards collect SAML assertions from incoming requests and assemble them into a "pod". This is Stuart's description from a private email:

    Having come to the position that there appears to be no easy way to use Shibboleth attributes for Sakai authorization, it appears that our most productive way forward may be to await Alistair Young's work to use the Guanxi distributed SP and Sakai "bridge" work. We would still use the Internet2 Shibboleth IdP/AA components - we are told that Guanxi has been successfully tested with these.

    It would appear that an advantage of Guianxi is that, as long as the authentication assertion is available, it is in principal possible to ask Shibboleth for additional attributes that are not present in the current "pod". (But it is not clear that Guanxi actually does this.) A single Service provider "engine" module can service multiple "guards", possibly across multiple domains, so SP deployment may be substantially simplified.

    3.3. Coordinating with other project partners

    Mike Fraser has suggested an approach to deployment that seems more manageable than that we had been pursuing. Rather than trying to roll out to the entire project partnership, we work initially with a single partner and get two Sakai platforms within the project to allow authentication of users from one site's Shibboleth IdP to enable access to the other site's Sakai installation.

    Of the partners, CCLRC already has a Shibboleth deployment and has engaged constructively in our discussions, so an approach to Rob Allan and David Spence would seem to be a useful next step.

    3.4. Sakai system performance problems

    It appears the main problem is insufficient memory, leading to thrashing when Sakai is loaded. We have investigated adding memory to our present machine, but it's already maxed. Stuart has asked the inhouse team if there are any possible machines gathering dust in a cupboard - nothing matching our requirements, but none meeting our requirements are currently available.

    We have decided to use a Xen virtual machine on the SPIE system hardware for our Sakai deployment. We can allocate 1Gb RAM to this machine, which we think should help to alleviate the performance problems we've been encountering. What follows are some notes about the plan for redeployment of our Sakai system in this environment.

    For reliable Java operation, we would need to use a recognized Linux distribution; mainly, the kernel must be a specific one tailored for Xen, and the Clib must also have the correct optimization options. Debian looks most suitable here. We would need to provide a system image and a machine room IP address.

    4. Notes for next meeting

    (Matters arising following the planning meeting.)


    [GK] Contact Alistair Young and advise him that we'd like to take advantage of his Guanxi/Sakai work, providing feedback and further testing to help harden this software. Done. See


    [GK] Contact CCLRC partners with a view to creating a bilateral Shibboleth authentication federation between our Sakai sites. Done. See

  • GK has had a series of email contacts with Steven Carmody, part of the Internet2 Shibboleth team, who has expressed some reservations about our adoption of Guanxi, and would prefer us to follow an approach that is more closely aligned with Internet2's own development plans. In particular, he is concerndd that Guanxi may not track the Shibboleth 2 developments. (If true, this would be a reason to not use Guanxi, since the longer term goals for Shibboleth deployment do include the "n-tier" problem, devolved access to non-web-facing services, which is not possible using Shibboleth 1.3.) The current state of discussion can be seen at

  • Added information about Sakai authorization architecture and Shibboleth integration to the page at SakaiVre/SakaiUserDirectoryProvider.

  • A problem was experienced with the new Sakai virtual machine, but this appears to have been a problem with the network interface in the host system.
  • TODO: investigate participation in AHM - 18-21 September, Nottingham.

  • -- GrahamKlyne 2006-08-07 19:00:18

    OSSWatchWiki: SakaiVre/PlanningProgress/20060807 (last edited 2013-04-15 13:56:19 by localhost)

    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.