Project index

Planning index

Project planning meeting - 19 June 2006

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

Last report: SakaiVre/PlanningProgress/20060605

This report: SakaiVre/PlanningProgress/20060619

Next meeting: 5 July 2006, 09:00 SakaiVre/PlanningProgress/20060705

Contents

1. Agenda

2. Activity since last report

The main activity has been completion of the initial Shibboleth installation, linked to OUCS WebAuth and LDAP services. This leads us to thinking about using Shibboleth with Sakai, and initial planning for a multi-site roll-out across the project partners. The next technical priority will be getting Sakai to use attributes provided by Shibboleth.

2.1. Actions closed

20060605.1

[GK] Review Stuart's notes on search requirements and FOAF (see SakaiVre/LDAPToFOAFIdea)

20060605.2

[SY] Review GK's notes on Shibboleth IdP installation (see ShibbolethInstallNotes)

20060306.2

[GK/SY - 20060526] Requirements and procedure to create a minimal Shibboleth deployment - ShibbolethInstallNotes. Our deployment has been completed using the Shibboleth InQueue federation, so the action to obtain SDSS federation credentials has been carried over as a new action.

  • We had continuing problems with Shibboleth IdP installation, amd went back to a virgin Tomcat installation. Further problems encountered related to getting all configuration files and security tokens in the right places, and Tomcat security configuration, but in the end an apparently working installation was achieved. The SP module is successfully installed and working. This too proved more difficult than the imnstallation notes would suggest, mainly in getting the configuration right. We discovered that a problem with getting an attribute assertion issued was due to earlier problems configuring port 8443 access, compounded by SELinux enfircement of prohibition of port listening by Apache server. With the Apache server permitted to listen on port 8443, we progressed with configuration of LDAP attribute authority and have this working. Stuart reports success in getting attributes released from our LDAP into the Shibboleth SAML assertion, achieved by editing the LDAP-to-shibboleth mapping, attribute release policy and attribute acceptance policy configurations.

2.2. Actions progressed

20060508.2
[GK - 20060512] Finish securing the Sakai VRE demonstrator host system:
  • Continue monitoring Logwatch for Sendmail activity (DONE: Sendmail does appear to be dormant, and log messages mentioning sendmail are considered to be artefacts).
  • Set up system backup via HSM (PENDING)
  • We had lunch with Kang Tang and Christian Fernau on Monday 5 June 2006, giving us some opportunity to informally discusss goals, progress, problems encountered, etc. Since then we have been collaborating loosely, but until now have been proceeding with a separate Shibboleth IdP installation because of our need to be able to replicate a deployment at other sites.
  • Following its removal while we worked on Shibboleth, the Sakai software has been reinstalled and is now working. We are running into performance problems on our Sakai service host, and probably need more memory to achieve a reasonable performance.
  • 2.3. New activities and notes

    20060619.1
    [GK] Obtain SDSS federation credentials, and jopin our IdP to the SDSS federation.
    20060619.2
    [GK] Review Stuart's notes about publishing LDAP attributes via Shibboleth (LDAP mapping, ARP, AAP).
    20060619.3
    [GK/SY] Investigate how to make Shibboleth attributes available for use in Sakai access controls (was previosuly part of action 20060301.9).
    20060619.4
    [GK/SY] Write Shibboleth configuration document, in particular showing how the various configuration elements and functions are inter-related.
    20060619.5

    [SY] Arrange more formal meeting with Christian Ferneau and Kang Tang to discuss (a) attribute passing models, (b) multi-federation protection of web pages, (c) deployment of shared Shibboleth IdP for Sakai and ShibGrid projects, (d) hardware and software platform deployment options (bearing in mind performance issues and a possible limitation of available machine room space; possible use of virtualization?).

    20060619.6
    [GK] Draft an email and wiki page to open discussion with other project partners about a multi-site Shibboleth deployment for the VRE project.
    20060619.7
    [SY] Prepare an initial list of attributes generated by OUCS LDAP, and the Shibboleth mappings used. This will be used to help seed project-wide discussion.
    20060619.8
    [SY] Investigate performance problems with our Sakai/Shibboleth demo machine, and propose appropriate upgrade or route resolution.

    3. Discussion

    3.1. Shibboleth installation

    We have now completed a local Shibboleth integration, linked to the OUCS WebAuth and LDAP services. Stuart has also succeeded in getting locally defined LDAP attributes released via Shibboleth. (See ShibbolethInstallNotes)

    Getting Shibboleth installed and running is no mean feat, maily due to the complexity of configuration involved at each stage. As a result, we feel that a broad-coverage Shibboleth installation document will be of use, and that this should be an outcome from our work (over and above what is already recorded in the local project wiki - ShibbolethNotes, ShibbolethInstallNotes).

    Stuart raised the matter that it might be desirable to allow multiple federations to control access to a resource, as there may be collaborative benefits in being able to work with different federations. Currently, it is not clear if this is possible; this is probably a question to ask the SPIE team.

    Stuart also noted that Christian had mentioned (at least) two possible models for attribute passing with Shibboleth, but wasn't clear of the details. We feel that this (too) is information we should capture and record.

    3.2. Coordinating with other project partners

    Now that we have a basic Shibboleth installation linked to our local WebAuth and LDAP attrribute services, we feel it is time to start planning for a project-wide deployment, taking account of other partners' institutional facilities and requirements.

    Specific points for discussion include:

    3.3. Other

    Mike Fraser noted in passing that a JISC report is required by 29 June. Most of the required information is probably in our wiki, but we should expect to provide (at least) a list of headings and links to the appropriate pages.

    4. Summary of ongoing actions brought forward

    20060605.3

    [SY] Update Sakai installation notes to reflect Java 1.5 installation (see SakaiNotes)

    20060508.2
    [GK - 20060512] Finish securing the Sakai VRE demonstrator system:
    • Continue monitoring Logwatch for Sendmail activity (DONE)
    • Set up system backup via HSM (PENDING)
    20060301.5
    [SY - 20060519] Analysis of search requirements.
    20060301.10
    [GK - 20060519] Add Shibboleth authentication to Sakai. We are now ready to start looking into this. See also, new action 20060619.3.
    20060301.9
    [GK - 20060605] 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.
    20060301.11

    [GK - 20060327] Investigate Sakai background technologies (Spring, JSF) (See SakaiNotes; TODO: input concerning JSF.)

    5. Notes for next meeting

    (Matters arising following the meeting)

    20060619.2

    [GK] Review Stuart's notes about publishing LDAP attributes via Shibboleth (LDAP mapping, ARP, AAP). DONE.

    20060619.1
    [GK] Initiate process of SDSS federation credentials. Have generated key and requested an SDSS CA certificate.
    20060619.6

    [GK] Draft an email and wiki page to open discussion with other project partners about a multi-site Shibboleth deployment for the VRE project. Sent: see SakaiVre/ShibbolethFederation.

    20060619.3
    [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.
    20060605.3

    [SY] Update Sakai installation notes to reflect Java 1.5 installation (see SakaiNotes) Done.

    20060619.5

    [SY] Arrange more formal meeting with Christian Ferneau and Kang Tang to discuss (a) attribute passing models, (b) multi-federation protection of web pages, (c) deployment of shared Shibboleth IdP for Sakai and ShibGrid projects, (d) hardware and software platform deployment options (bearing in mind performance issues and a possible limitation of available machine room space; possible use of virtualization?). Done. See: SakaiVre/ShibbolethPlanning/20060621 (and emails).

    20060619.7

    [SY] Prepare an initial list of attributes generated by OUCS LDAP, and the Shibboleth mappings used. This will be used to help seed project-wide discussion. Done. See: SakaiVre/AttributeMappingsTable.

    20060508.2
    [GK - 20060512] Finish securing the Sakai VRE demonstrator system:
    • Set up system backup via HSM
      • Initial installation and backup - done.

      • Configure schedule for automatic backup - done; monitor logs to ensure correct operation.

      • See SakaiVre/MachineStatus

  • On 2006-06-21, we have decided to undertake some housekeeping on the Shibboleth/Sakai host system: there is a kernel upgrade to install, old log files to clear out, and the system needs rebooting to ensure all services start up OK. Also will try to install TSM backup client today. (TSM setup notes for a similar system are here: http://www.ontonet.org/moin/ServerConfiguration/BackupUsingTsm.)

  • Related to the previous point, document key services we are using, with init.d script file name (if any) and location of log files. See SakaiVre/MachineStatus.

  • Created a wiki page about MyProxy, as this affects the ShibGrid project's use of Shibboleth.


  • -- GrahamKlyne 2006-06-19 08:10:41

    OSSWatchWiki: SakaiVre/PlanningProgress/20060619 (last edited 2013-04-15 13:56:16 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.