Project index

Planning index

Project planning meeting - 8 May 2006

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

Last report: SakaiVre/PlanningProgress/20060424

This report: SakaiVre/PlanningProgress/20060508

Next meeting: 5 June 2006, 09:00 SakaiVre/PlanningProgress/20060605

1. Agenda

2. Activity since last report

2.1. Actions closed

20060301.8

[GK/SY - 20060313] Install Sakai. Problems were a combination of local oversight and difficulty in locating the correct documentation on the Sakai web site. That's all cleared up now. latest installation details are at SakaiNotes#installation

2.2. Actions progressed

20060306.2

[GK/SY - 20060526] Requirements and procedure to create a minimal Shibboleth deployment. Considerable progress has been made: see discussion below. Stuart has documented expected Shibboleth interactions with Sakai and WebAuth: see SakaiVre/ShibbolethWebAuthIntegration.

20060301.5

[SY - 20060327] Analysis of search requirements. Stuart has been in contact with Chris Awre (Hull) about Google, GetRef and Jafer portlets, and has copies of the relevant software. There may be some administrative difficulties: see discussion below.

20060301.9
[GK - 20060605] Port SPIE Shibboleth/WSRP (cf. work by Jasper Tredgold) to Sakai. No specific progress, but as we gain a clearer understanding of how the WebAuth/Shibboleth interactions will work (see 20060306.2), this is looking as if it should be relatively easy to achieve once the Shibboleth part is deployed. The main remaining unknown is to somehow get Shibboleth attributes into the Sakai portal framework.
20060301.10
[GK - 20060605] Add Shibboleth authentication to Sakai. No specific progress, but this is looking easier in light of progress on 20060306.2. We hope to have key software for this installed and running in the coming week.

2.3. New activities and notes

20060508.1

[GK - 20060508] Review Stuart's notes about WebAuth and Shibboleth.

20060508.2
[GK - 20060512] Finish securing the Sakai VRE demonstrator system:
  • Install SSHBlack to reduce logwatch report sizes, improve security and reduce attack traffic
  • Turn off sendmail (using postfix). (I thought I'd done this, but logwatch shows sendmail is still active.)
  • Set up system backup via HSM
  • GK has had an informal discussion with David Wallom about campus grid authentication requirements. David needs a Shibboleth set-up very similar to the Sakai VRE demonstrator (plus grid interfaces). We agreed to have some more definitive discussions, but no time has yet been arranged.
  • Stuart has arranged Kerberos (WebAuth) user accounts so that we can configure WebAuth-based authentication (Kerberos ticket-granting) for the Sakai VRE demonstrators. (Terminology here may be a bit mangled.)

  • GK gave an RTS talk about the role of standards in complex networked system design:
  • 3. Discussion

    3.1. Sakai installation

    Sakai installation problems are now resolved: it turns out we were using an old version of the software. Previously mentioned problems with the software should be disregarded.

    3.2. Shibboleth installation

    Stuart has documented expected Shibboleth interactions with Sakai and WebAuth: see SakaiVre/ShibbolethWebAuthIntegration. We now have a far better understanding of how WebAuth should be fitted in to the overall environment (i.e. as an Apache authorization module; no new code should be required). We believe we have now identified all the required components.

    We discussed Shibboleth installation and federation with Christian Ferneau; the SPIE project has a running Identity Provider (IdP) that we could use, with links to three federations: SPIE (internal), SDSS (see: http://sdss.ac.uk/), and InQueue (Shibboleth test federation). We believe that for the Sakai VRE Demonstrator, SDSS is an appropriate federation. Once we have a stable Shibboleth identity provider, with documented interactions, that should be readily usable by other Shobboleth-using projects.

    The "master plan" for progressing this strand of activity is now:

    1. Install Kerberos software, needed to access WebAuth administration interface

    2. WebAuth on an Apache HTTPD server, with some dummy pages to test the access control setup.

    3. Install Shibboleth, linked to the SDSS federation and using WebAuth authentication. (WebAuth and Shibboleth should interact via normal Apache server control and filtering mechanisms.) (See: SakaiVre/ShibbolethInstallNotes-20060322)

    4. Install Shibboleth authentication interface on the Sakai server

    3.3. Search portlets

    Google portlet: needs a ticket from Google that limits number of queries that can be made. May be restrictive in a portal-style environment. We now have a copy of the source, but this is no longer being maintained and is not available from any kind of public source repository, so future utility of this component is questionable.

    GetRef (find accessible copy of paper given summary/abstract information). Depends upon a service operated by Edina, so long-term viability is uncertain. Also, like the Google portlet, this is not maintained in a public source repository.

    JAFER (). Is maintained from a public source repository.

    Refs:

    There are possible difficulties to be resolved here because the administration of these portlets may not be an easy fit with the Shibboleth-style federated authentication approach. We may end up mangling some trust models (cf. the WSRP support) to make things fit.

    Note: the above comments suggest that maybe a common source repository, like Sourceforge, should be identified as a resting place for all JISC-funded (and other UK academic OS projects).

    4. Summary of ongoing actions

    20060306.2

    [GK/SY - 20060526] Requirements and procedure to create a minimal Shibboleth deployment. Note: completion estimate revised. A possible option is to simply use the SPIE Shibboleth server, but we feel that we should at least install one to better understand what is involved. Then we can decide which installation to use for the Sakai demonstration system.

    20060301.5

    [SY - 20060519] Analysis of search requirements. Note: completion estimate revised. Progressing. Now focusing more on specific portlets. See discussion above.

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

    [GK - 20060519] Add Shibboleth authentication to Sakai: we apear to be ready to move forward on this. Note: completion estimate revised.

    1. [20060519] Install Shibboleth toolkit
    2. [20060519] (Sakai installation dependency) Link Sakai authentication to Shibboleth
    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)

    20060508.1

    DONE. (Review Stuart's notes about WebAuth and Shibboleth. See SakaiVre/ShibbolethWebAuthIntegration

    20060306.2

    Stuart has succesfully installed a Kerberos principal to interact with the local WebAuth system.

    20060306.2
    More details for the "master plan" (cf. discussion section 3.2)
    1. Test case: use WebAuth to protect static pages served by Apache HTTPD server

    2. Shibboleth linked to SDSS federation:
      1. Need to apply for membership of SDSS federation.
      2. Install Shibboleth and link to WebAuth. Test case: Shibboleth-controlled access to locally served pages based on WebAuth credentials.

      3. Obtain SDSS test account based on remote credentials. Also, identify remotely-served test pages (i.e. outside WebAuth domain).

      4. Test case: Shibboleth-controlled access to locally served pages based on remote credentials.
      5. Test case: Shibboleth-controlled access to remotely served pages based on local WebAuth credentials.

      6. Test case: Shibboleth-controlled access to remotely served pages based on remote credentials.
    3. For the time being, we have obtained details for InQueue federation membership to test our installation

    4. Install mod_jk for communicating between httpd and Tomcat.
    20060508.2
    GK has installed SSHblack on the demo system, but it appears to be not working yet. [later] I've looked at the logs and iptables, and it does appear to be working. The large number of attacks logged may have been a hangover from old system log files.
  • On VRE demo host, create /etc/init.d/tomcat to hook startup into chkconfig/service/Redhat auto system startup.
  • Next progress meeting: reschedule to 5 June 2006

  • -- GrahamKlyne 2006-05-08 11:11:38

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