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
- Review agenda
- Confirm date/time of next meeting
- Review actions outstanding at last meeting
- New activities and issues arising from current work
- Discussion of specific issues
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
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.)
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:
Install Kerberos software, needed to access WebAuth administration interface
WebAuth on an Apache HTTPD server, with some dummy pages to test the access control setup.
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)
- 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:
Google portlet: http://www.hull.ac.uk/esig/cree/portlets/gportlet.war (source and binary).
GetRef portlet: http://www.hull.ac.uk/esig/cree/portlets/getref.war (source and binary).
JAFER portlet: http://www.jafer.org/, http://www.jafer.org/source/wsvn/JAFER/ for source in subversion
http://www.hull.ac.uk/esig/cree/ CREE project page, home to the above.
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.
- [20060519] Install Shibboleth toolkit
- [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)
Test case: use WebAuth to protect static pages served by Apache HTTPD server
- Shibboleth linked to SDSS federation:
- Need to apply for membership of SDSS federation.
Install Shibboleth and link to WebAuth. Test case: Shibboleth-controlled access to locally served pages based on WebAuth credentials.
Obtain SDSS test account based on remote credentials. Also, identify remotely-served test pages (i.e. outside WebAuth domain).
- Test case: Shibboleth-controlled access to locally served pages based on remote credentials.
Test case: Shibboleth-controlled access to remotely served pages based on local WebAuth credentials.
- Test case: Shibboleth-controlled access to remotely served pages based on remote credentials.
For the time being, we have obtained details for InQueue federation membership to test our installation
- 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.
-- GrahamKlyne 2006-05-08 11:11:38

