Shibboleth
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
<ApplicationDefaults id="default" policyId="default" entityID="https://sakai.arcs.org.au/shibboleth" REMOTE_USER="mail eppn persistent-id targeted-id" signing="false" encryption="false">
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.
top.login=false container.login = true # Login icon (uses container auth) login.text=Federation Login login.icon=/library/image/aaf_login.png # Controls 2nd button (bypasses container auth) xlogin.enabled=true xlogin.text=Login Others login.use.xlogin.to.relogin = true nonOfficialAccountSectionTitle=Federation users and other users nonOfficialAccountLabel=Enter email address
Configure Apache HTTPD
Protect the sakai login tool container path by adding the following in /etc/httpd/conf.d/shib.conf
<Location "/sakai-login-tool/container"> AuthType shibboleth ShibUseHeaders On ShibRequireSession On require shibboleth </Location>
Configure Tomcat
Disable Tomcat's container authentication by adding the parameter tomcatAuthentication="false"
to the connector configuration ($CATALINA_HOME/conf/server.xml
):
<!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" enableLookups="false" redirectPort="8443" tomcatAuthentication="false" URIEncoding="UTF-8" protocol="AJP/1.3" />
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
.