Extension:SimpleSAMLphp

The SimpleSAMLphp extension extends the  extension to provide authentication using [https://simplesamlphp.org/ SimpleSAMLphp].

Configuration
Values must be provided for the following mandatory configuration variables:

In addition, the following optional configuration variables are provided:

Define custom user info provider
If you want to modify any of the fields  ,   or   before login, for instance, if your SAML source does not provide an explicit username attribute and you want to use the email address without the domain for the username, you can configure a custom callback for  . The factory method has the following signature:

For simple usecases one can use  , assuming your email attribute is called <tvar|2> </> (if it's called something else, change the two instances of <tvar|3> </> to <tvar|4> </>):

Group mapping
Use case: your SAML IdP reads groups from LDAP or Database and stores this information inside an attribute of the SAML response. You want to use this to map MediaWiki groups to users belonging to some known groups given by your IdP.

Example:


 * Your IdP sends an attribute named "groups" with a list of names like "administrator", "student", "teacher", ... in the SAML response after authentication.
 * All users that have the value "administrator" in the "groups" attribute shall be mapped to the MediaWiki "sysop" group to give them admin rights within your MediaWiki instance.
 * Create a group map in your LocalSettings.php as follows:

You can come up with rather complex mappings that fit your needs. If you have more than one attribute from SAML, just add it to the array with the array of values you like to map.

If a MediaWiki group does not exist, it will be created "on the fly" on first successful mapping of a user.

Group mapping #2
Since version 4.3 one can also configure an alternative group synchronization mechanism. Besides the default "MapGroups" one can use "SyncAllGroups", which takes all groups from the SAML response and assign the user to them.

To do so, add the following to the <tvar|1> </>:

If the IdP returns group names that are not suitable for the wiki, one can set up a callback to modify the group names. E.g. some IdP-Setups may return LDAP-DNs like "CN=Admin,OU=Groups,DC=SomeDomain". One could then specify in <tvar|1> </>:

Processing arbitrary data from the SAML response
The "attribute processors" can also be used to handle arbitrary data from the SAML response. In this case one must first create a new PHP class that implements the <tvar|1> </> interface. For convenience the base class <tvar|1> </> can be used, which has a proper factory callback and constructor implemented. An example

It then needs to be instantiated by using the.

Release notes

 * Version 4.5.2
 * fixed bug: Groups are not removed in MW if the attribute is not existing (<tvar|1>T246351</>)
 * Version 4.5.1
 * fixed warning: <tvar|1>$wgSimpleSAMLphp_GroupMap</> is not an array
 * improved loading UserInfo and Groups
 * improved tests
 * Version 4.5
 * added support for custom user info providers
 * updated to manifest version 2
 * Version 4.4
 * Fixed signature of populateGroups function to match Extension:PluggableAuth/Hooks/PluggableAuthPopulateGroups hook
 * Version 4.3
 * Added support for attribute processors
 * Fixed bug in SAML attribute processing
 * Added PSR-4 compatible namespace
 * Dropped support for MW <1.31
 * Version 4.2
 * Broke out username, real name, and email functions so they could be overridden in a subclass to allow custom rules
 * Coding style and directories
 * Improved debugging
 * Version 4.1
 * Implements Extension:PluggableAuth/Hooks/PluggableAuthPopulateGroups hook to populate MediaWiki groups from SAML attributes. Thank you to Poikilotherm for contributing this functionality.
 * Version 4.0
 * Added optional error message to authenticate
 * Bumped version number to synchronize with PluggableAuth and OpenID Connect extensions

Debugging
SSO can be difficult to configure correctly, especially for first-time sysadmins tasked with connecting their new MediaWiki instance to the company's IdP. The PluggableAuth and SimpleSAMLphp extensions themselves are quite stable, so most issues are usually associated with configuration.

To start debugging, set $wgDebugLogFile to a filepath on your local system. You do not need to set $wgShowExceptionDetails to true; in fact, you probably shouldn't, due to security concerns.

Visit your wiki, and try logging in with PluggableAuth. Once you have encountered your error, visit the debug file and look for lines that start with  and.

If there was an issue with authentication, the debug log will say  somewhere.

The SimpleSAMLphp extension works like this:


 * 1) User clicks on SSO login button on wiki.
 * 2) User is taken to Special:PluggableAuthLogin. It detects the wiki is using Extension:SimpleSAMLphp. SimpleSAMLphp (the software, not the extension) detects no login session has been set yet.
 * 3) Special:PluggableAuthLogin calls Extension:SimpleSAMLphp's   function, which calls SimpleSAMLphp's API to begin the authentication process.
 * 4) SimpleSAMLphp redirects user to the IdP's login page.
 * 5) After user successfully authenticates with IdP, it generates an assertion and redirects to your local SimpleSAMLphp instance's ACS (assertion consumer service) URL, which then redirects to the wiki's Special:PluggableAuthLogin.
 * 6) Special:PluggableAuthLogin now recognizes the session cookie and handles logging the user in.

If you are encountering a login redirect loop, the authentication process will never have a chance to log either an error or success message. This indicates that the call to SimpleSAMLphp's  method never finishes, which means SimpleSAMLphp is trying to start the auth process all over again. This is usually because it is not detecting the login session despite it being set. Make sure you are not making common mistakes, such as not setting your SimpleSAMLphp store to a DB-based method, or putting your SimpleSAMLphp instance on a different domain than your wiki without a proper proxy. (For instance, if your SimpleSAMLphp instance is at the canonical domain  but your wiki is located at , the session will never be stored on   and Special:PluggableAuthLogin will redirect back to the IdP instead of logging the user in, creating a login loop.)

If you are encountering an error message on Special:PluggableAuthLogin after a successful redirect from the IdP, there is probably a PluggableAuth/SimpleSAMLphp misconfiguration in your LocalSettings.php. Check to see if you properly configured your attributes. The attributes may sometimes need to be URLs (such as if you are using Azure Active Directory).

Known bugs
If you are using MediaWiki 1.27 or later with PluggableAuth 2.0 or later, problems have been observed when SimpleSAMLphp is configured to use <tvar|1>phpsession</> for <tvar|2>store.type</>. This may be due to <tvar|1>T147161</>. To fix this, use a different store type in the configuration of the [<tvar|url>https://simplesamlphp.org/</> SimpleSAMLphp software] by adjusting <tvar|1>simplesamlphp/config/config.php</> (see <tvar|url2>https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_2_3</>). For example, for SQLite, use:

'store.type' => 'sql', 'store.sql.dsn' => 'sqlite:/path/where/the/apache/user/can/write/sqlitedatabase.sq3',

For MySQL, use:

'store.type' => 'sql', 'store.sql.dsn' => 'mysql:host=xxx;port=xxx;dbname=xxx', 'store.sql.username' => 'xxx', 'store.sql.password' => 'xxx',