You'll need the following pre-requirement:
You are strongly encouraged to use a SimpleSAMLphp session storage other than the default phpsession.
There are other SAML plugins for Moodle and the panorama could be confusing. Below are the main differences between this plugin, named internally as auth_saml2sso, and the others:
The key for this plugin is that you can use your exists Service Provider (SP) without needed to exchange the metadata with the Identity Provider (IdP) for every new Moodle instances. (for instances in the same host name)
To override the authentication and login directly in Moodle (ex.: using admin account), add the saml=off parameter in the URL (ex.: https://my.moodle/login/index.php?saml=off)
You cannot upgrade directly from Moodle < 3.4, because incompatible functions. In the case, you must perform an intermedial upgrade step to a Moodle >= 3.4 and < 3.9 with a plugin version < 3.10.
The feature to break the full name from IdP into firstname and lastname has been removed because inconsistencies in results. If you can replace it with a SimpleSAMLphp authproc filter: see below.
Some static methods in SSP 1.x have been migrated to non-static in SSP 2.x; older version of this plugin (<2023071100) could raise errors during signoff if used with SSP 2.x library.
According Moodle documentation, SSO-auth modules don't apply "limit concurrent logins" restriction.
https://tracker.moodle.org/browse/MDL-62753?jql=text%20~%20%22session%20kill%22
https://moodle.org/mod/forum/discuss.php?d=387784
Probably this is due to the mismatch between the Moodle session and the local SSO session.
Since SimpleSAMLphp API can interact with the local SSO session, this plugin supports the concurrent logins limit if it is set to 1. This is a common scenario for exams, while limits > 1 have not clear purposes.
SAML Single Sign Off (or better SLO - Single LogOut) is a tricky topic, Scott Cantor wrote a wide overview of the problem in the Shibboleth wiki. Regarding this Moodle plugin:
The only reliable SLO procedure remains to close the browser.
One of the distinctive feature of the first release of SAML2 SSO plugin was the ability to break the full name from IdP into the first name and the last name. It was related to the old version of Moodle auth base plugin and this feature will be removed in the next release.
Nowadays, adminting there are some IdPs still serving the full name and not the first and last name (such as givenName and sn in LDAP idiom) you can use a SimpleSAMLphp authproc.
For example, in order to replicate the old behaviour if you receive the full name in the attribute urn:oid:2.5.4.3 (e.g. from a Shibboleth IdP) you can add to the authsource or to the IdP metadata:
'authproc' => array(
array(
'class' => 'core:PHP',
'code' => '
// First name attribute
$attributes["givenName"][] = strstr($attributes["urn:oid:2.5.4.3"][0], " ", true)
? strtoupper(trim(strstr($attributes["urn:oid:2.5.4.3"][0], " ", true)))
: strtoupper(trim($attributes["urn:oid:2.5.4.3"][0]));
// Last name attribute
$attributes["sn"][] = strstr($attributes["urn:oid:2.5.4.3"][0], " ")
? strtoupper(trim(strstr($attributes["urn:oid:2.5.4.3"][0], " ")))
: strtoupper(trim($attributes["urn:oid:2.5.4.3"][0]));
',
),Or, to emulate it in a compact way:
'authproc' => array(
15 => array(
'class' => 'core:AttributeAlter',
'subject' => 'urn:oid:2.5.4.3',
'pattern' => '/^([^ ]+)/',
'target' => 'givenName',
'%replace',
),
16 => array(
'class' => 'core:AttributeAlter',
'subject' => 'urn:oid:2.5.4.3',
'pattern' => '/([^\\s]+)$/',
'target' => 'sn',
'%replace',
),And then mapping the attribute givenName and sn as usual.
See the SimpleSAMLphp documentation on Authproc.
SAML-based authentication services couldn't provide a user list suitable for users synchronization. But, in scenarios with a single IdP within the same organization (no discovery nor federation) is common that the IdP uses LDAP or a SQL DB as authentication backend.
You can configure the LDAP or DB Moodle auth plugin in order to access to that backend, leaving the plugin itself disabled, and configure SAML2 SSO auth to obtain user list from it.
A special page handles user migration from plugin based on external backend to SAML2SSO. Users handled by the internal Moodle authentication cannot migrate because no "authority" can guarantee match between Moodle username and SSO one.
As described in the introduction, some plugins is not compatible with recent Moodle releases. The migration feature take in account even users belongin to missing plugins.
SimpleSAMLphp is more than a SAML library: it is also an adapter layer that can handle several auth sources in a uniform way.
Then SAML2SSO plugin can seamless authenticate against Facebook, LinkedIn, Twitter, advanced LDAP and multi-LDAP sources, .htpasswd files, etc.
See SimpleSAMLphp manual for more documentation.