Sorry for the delay in replying. I've been trying to work to a deadline, and some things have got a bit left behind.
The good news is that we have been running XOT with Shibboleth for a couple of weeks now with no problems.
There is bad news though. The docs suggest using the 'php-saml' software. We installed this and configured it as best we could, but we always received an encryption error from the IdP. I spent some time looking at this, but didn't really get anywhere.
So, instead, we decided to use the Shibboleth consortium software from
shibboleth.net/ . We have used this software on other servers with no problems, and since we are running CentOS on the XOT server we can just download the RPM and install that.
Installation of the software also creates the SP metadata (I think. We changed ours a couple of times using a script which is provided to recreate the metadata. If it isn't created automatically, then just run the 'metagen.sh' script). It also installs an Apache module/config file used for talking between Shibboleth and Apache. The Shibboleth software does require configuration in that the SP metadata needs to be configured into the IdP, and the IdP metadata into the SP (which basically just involves copying a file from one server to the other). The SP config file (/etc/shibboleth/shibboleth2.xml) needs to be configured in that it needs to be told where the IdP is located, what attributes to expect and what the SP entityID is. The 'attribute-map.xml' file may also need to be modified depending on what attributes you are going to use.
On the IdP side, this needs to be configured to recognise the SP entityID, and release whatever attributes are required. (We release a few attributes by default, but in this case the unscoped-affiliation is the one we mainly want.)
It might all sound a bit complicated, but to be honest once you've set up the SP and reconfigured the IdP a couple of times it becomes quite easy. (We use the same
shibboleth.net software on our IdP as well.)
Once it's all set up, then start the 'shibd' process on the XOT server. The installation docs on
shibboleth.net will give you some info about how to test that the IdP and SP are talking to each other. Running 'lynx https://localhost/Shibboleth.sso/Status' from a console on the server itself will give you a quick idea if they are talking to each other. If you get some gibberish output, then it's working. If you get some sort of error, or no output, then it's not working.
the SP software provides log files in two directories. The shibd output is in '/var/log/shibboleth', and this will show you the attributes being received in the transaction log. (The attribute values are not shown.) Other errors may appear in the '/var/log/shibboleth-www' directory.
The Apache shibboleth module, by default, sets up a '/secure' directory which requires shibboleth authentication. So for testing just create the 'secure' directory in your web server document root, and drop in there a simple PHP file containing a call to 'phpinfo()'. Using a browser, access the file and you should be prompted by your IdP for login credentials. The phpinfo call should dump a load of PHP info in the browser, and near the bottom should be the $_SERVER variables. Amongst them you should see the Shibboleth attributes you have requested. So for example, "$_SERVER", "$_SERVER" etc. So far so good, you now have Shibboleth, Apache and PHP all talking.
The last part is now to get XOT to call Shibboleth when the 'Login' button is clicked, and to use the variables to check the user is allowed to log in or not. This requires writing a shortish PHP script, which I based on the 'Saml2.php' script. I called this file 'Shibboleth.php'. This goes into the 'library/Xerte/Authentication' directory under your web server document root.. I see no way round writing the script since what attributes a site wants to use could be anything, so it will at least require modifying any provided script just as with the current 'Saml2.php' script. That is, I don't think Xerte can automate this part of the installation process because it will vary from site to site. Secondly, the 'auth_config.php' file must be changed to use the 'Shibboleth' login method (that is what we called it, but others can obviously call it whatever they want. The name must match the filename used above). Finally, the 'login_library.php' file must be changed to recognise the shibboleth method, and the 'index.php' file to cater for the Logout button. I'll attach (hopefully) copies of the changes made.
When the login button is clicked the user is taken to the URL '/Shibboleth.sso/Login?target=xxx'. and for the Logout button the location is '/Shibboleth.sso/Logout?return=xxx'. In both cases the 'xxx' is the URL of the XOT server (xerte_toolkits_site->site_url). So there is no need for any extra code to handle replies to or from the SP or IdP (the shibd process does all that). It also means that when the Logout button is clicked, the user is returned to the Login page (because index.php sees them as not logged in).
In our case we have made some other changes for Shibboleth. All users must be presented with the login page initially. That is, it does not automatically log them in immediately. The user must click on the login button (whether they get prompted for their userid/password of course depends on whether they have used Shibboleth SSO to log in to some other service first). Secondly, the userid and password boxes have been removed since they are not required. It may only confuse the user to enter their credentials and then click the login button (and sort of defeats SSO). Finally, the 'Logout' button logs them out of XOT but also out of the current Shibboleth session, and returns them to the XOT login page. So any other SSO session (to some other service) will still work, but to enter XOT again they must again click on the Login button (obviously they won't be prompted for a userid/password if the IdP still recognises their credentials as valid). Other sites may or may not want to do the same. As such the Xerte developers may or may not want to include all or any of the changes we have made (or even make some of them configurable via the management interface?).
Since Shibboleth is provided as an authentication method with Apache, you can setup various locations/directories so that only authenticated users can access them. The USER-FILES, print and editor directories seem like good ones to use. The Apache authentication configuration is set up the same as was provided for the '/secure' directory. So before being able to do anything of any use, users must be authenticated.
That's it really. Again, it might seem complicated, but in fact there were only a few changes required to the XOT code, and all the IdP/SP traffic is handled by the shibd process.
