Skip to end of metadata
Go to start of metadata

This page provide some instructions to enable Shibboleth integration. The original work is done by Stockholm University

Changes to the Original Work

Some works are performed to accommodate requirements to enable universities and research organization to use Sakai, irrespective whether the institutions are part of the Shibboleth federation or not.

Some additional features and modifications to the original work are:

  • Ability to invite federation users by their email address than their eppn
  • Non-federation users can access sakai using Guest account. The guest account will be converted to federation account when s/he login using Shib IdP for the first time.
  • If a user from Shibboleth federation is added to a site and has not been logged in to Sakai previously, a guest account (and password) will be created for the user.
  • Since WebDAV clients cannot use Shibboleth, WebDAV access is authenticated separately using Sakai, e.g. the password are stored using SAKAI_USER table. No need to use or configure RADIUS/other authentication method.
  • Adding participant to site (Site Info -> Add Participants) only use one text box which can be used to add both guest and federation accounts by their email address. Rationale: users do not know who is in the federation or not.

This work is deployed on https://sakai.arcs.org.au.

Installation and Configuration

Install Shibboleth SP

First, install Shibboleth SP and ensure that it works well without Sakai. See Shib2 installation guide from Internet2. Inspect attributes received from Shibboleth IdP from shibboleth log: /var/log/shibboleth/transaction.log.

Then, configure Shibboleth SP to use mail for REMOTE_USER

Apply the patch to Sakai

The ANU patch is based on the Stockholm University's patch. The patch is tested on Sakai 2.5.5. Download the patch

PS: Some hack to handle login.use.xlogin.to.relogin is placed that need to be reviewed. The idea is to redirect to xlogin page which contain login form for guest/local/admin users and link to login using Shibboleth Federation.

Configure Sakai

Edit sakai.properties to enable container login and use xlogin to relogin.

Configure Apache HTTPD

Protect the sakai login tool container path by adding the following in /etc/httpd/conf.d/shib.conf

Configure Tomcat

Disable Tomcat's container authentication by adding the parameter tomcatAuthentication="false" to the connector configuration ($CATALINA_HOME/conf/server.xml):

Troubleshooting

When IdP is not configured properly for Sakai (e.g. not releasing mail attributes), users from that IdP will get the following error after successfully authenticated to the user’s IdP:

HTTP Status 404 - /sakai-login-tool/
type Status report
message /sakai-login-tool/
description The requested resource (/sakai-login-tool/) is not available.

To resolve this, check whether the IdP releasing mail attribute in the log files in /var/log/shibboleth/ (shibboleth.log and transaction.log) in the SP machine, and make sure that scoped attributes in shibboleth are configured properly. To redirect user to a page when this issue happened, set the shib.nouser.redirect.url in sakai.properties.

Attachments

  File Modified
File ANU-ARCS-Shib-Sakai.patch Mar 01, 2011 by Denny

1 Comment

  1. Tuakiri, New Zealand Access Federation has just been established by staff at The University of Auckland, University of Canterbury and Landcare Research. As part of this project, I have recently patched a development instance of Sakai 2.8 (patch to be rolled out into production in the near future). We made a few minor changes to the Stockholm University patch for Sakai 2.6: