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
- 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_USERtable. 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:
Then, configure Shibboleth SP to use mail for REMOTE_USER
Apply the patch to Sakai
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.
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
Disable Tomcat's container authentication by adding the parameter
tomcatAuthentication="false" to the connector configuration (
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
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
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