Hey guys,
I’m running the latest 1.8 beta available on Docker, but the instructions for setting up SAML seem out of date. I tried to figure it out but failed, The routes don’t even seem to be available–has that feature shipped yet?
Is this the documentation you’ve looked at?
The SAML implementation is available in 1.8, but has to be manually configured (for now). Critically to make the routes available you need add the SAML Middleware to your settings.php file as described above.
Have you done that? Are you experiencing an error with it?
Hi Dan,
Sorry for the late reply. We have a number of other organizational priorities that are getting in the way of my priorities–namely, getting Xibo production-ready. 
The documentation that I followed is the same as the one you provided. I edited /var/www/cms/web/settings.php to include the variables suggested the docs, but it seems to have no effect. I was a little confused that the docs say to “change” $authentication to the specified middleware since that variable did not already exist.
This is what’s in the Docker image’s settings.php right now:
<?php
/*
* Xibo - Digital Signage - http://www.xibo.org.uk
*
* This file is part of Xibo - and is automatically generated by the installer
*
* You should not need to edit this file, unless your SQL connection details have changed.
*/
defined('XIBO') or die(__("Sorry, you are not allowed to directly access this page.") . "<br />" . __("Please press the back button in your browser."));
global $dbhost;
global $dbuser;
global $dbpass;
global $dbname;
$dbhost = $_SERVER['CMS_DATABASE_HOST'] . ':' . $_SERVER['CMS_DATABASE_PORT'];
$dbuser = $_SERVER['CMS_DATABASE_USERNAME'];
$dbpass = $_SERVER['CMS_DATABASE_PASSWORD'];
$dbname = $_SERVER['CMS_DATABASE_NAME'];
if (!defined('SECRET_KEY'))
define('SECRET_KEY','secretkey');
Have these variables moved elsewhere? I feel like I may have missed something, but I don’t know what that would be.
Found the problem! I think the script is extracting the Xibo default settings.php over my edited copy that I mounted. Mounting the file as read-only fixed the issue for me.
What is the long-term plan for supporting edits to the Docker image’s settings.php file?
Ah ha - yes that is a bit of an issue! Great that you found the problem though - does that mean the SAML flow is working for you?
@alex - this is an interesting point! we should discuss and work that out.
The SAML flow is working perfectly, except for two things… We’re using Google as our IdP, but the only unique id that they offer as an attribute is the email address. Xibo does not currently allow usernames to be email addresses so I’m forced to use names as usernames.
Firstly, Is there any chance that you guys could…
a) Add support for email addresses as usernames.
b) Allow concatenation of attributes to form a Xibo username ("[FirstName][LastName][Timestamp]")
c) Gracefully handle JIT when a user already exists.
d) Randomly generate a numeric username. (i.e. “sso-123456”)
c) Automatically reformat unsupported characters in the username to supported ones. (i.e. user@example.com becomes “user-example-com”)
Option C might already be a thing, but I don’t see it documented. In that version of events I could use FirstName as the attribute, but if Diane already exists then we’d move to Diane2 and so forth.
Secondly, I can’t figure out how to populate the reference data from SAML.
All this said, the implementation is probably good enough for most people.
Thanks for the great work!
Well settings.php used to live outside the container so it could be easily edited but @brodkin suggested moving it inside, and I deferred to his greater knowledge of Docker.
I think probably the easiest way will be to have an include directory, which maps to outside the container, which can contain custom config files which are then added in to the settings.php at run time. That allows configuration of custom middleware.
@alex If you look back to our previous conversations, I made the recommendation only if settings would be set exclusively via environment variables. It appears that there may be additional variables that can set in that file which are largely undocumented.
That said, most applications do store these settings into the database. Doing so would be your best long-term option as well. For the short term you could include settings from a new inc directory or use the existing userscripts directory.
I think it’s pretty unfair to say that the SAML config is undocumented! It has a section in the manual explaining what is required in that file to make it work.
I’ve logged an enhancement request for an inc directory and we’ll look at that in due course. I don’t think the userscripts directory is suitable as it’s web-servable and these inc files don’t need to be accessible that way.
@alex, I’m sorry if I offended you. My use of “undocumented” may be a bit harsh, but I will stand by the file format being “under-documented.”
Browsing the settings and configuration sections of the Tempel documentation, there seems to no mention of the settings.php file at all. If one needed to make a change after the wizard had been run, they’d be left in the dark. Similarly, the file shipped in the Docker container does not have $authentication or $samlSettings defined anywhere.
I would encourage you to look at the way that Laravel handles highly-complex configuration via environment variables. You can read up on it in their docs here and see an example of how they create their config files here. Xibo could use a similar approach to set sensible defaults, override in test, and still allow values to be configured via file. The thing that would be most valuable, however, would be the extensive commenting that they use to explain how values should be configured. With that, there would be no need to copy and paste that array from the manpage.
The intention was to enhance SAML with a configuration page in the CMS itself once it became a more pressing concern - at the moment we (or I would be more appropriate) decided it was more like a one-time install thing and that editing the settings.php file would be the way to go.
The other items that can be configured in the settings.php file are for additional middleware to be wrapped around the application stack - my feeling at the time was that this would be very difficult to achieve via a config at runtime - but perhaps it wouldnt.
Perhaps this could be the /custom folder we already have? settings.php could look for custom-config.php in that folder - this negates the requirement for adding an additional mapped folder anywhere in the structure.
I do not see why that won’t already work? you’d just change [workflow][mapping][UserName] to your mail identifier from the IdP. As well as your field_to_identify. Admittedly this would mean your user record had the same values for username and email, but I would have thought it would work.
You are right about that - those fields aren’t mapable - i’ll submit an enhancement.
I am glad it is generally working OK 