Extension:SimpleSAMLphp/fr

L’extension SimpleSAMLphp utilise l’extension PluggableAuth extension pour fournir une authentification en utilisant SimpleSAMLphp.

Configuration
Les valeurs doivent être renseignées obligatoirement pour les variables de configuration obligatoires :

Variables de configuration optionnelles :

Définir le fournisseur d’informations utilisateur personnalisé
Si vous souhaitez modifier l'un des champs,   ou   avant la connexion, par exemple, si votre source SAML ne fournit pas d'attribut de nom d'utilisateur explicite et que vous souhaitez utiliser l'adresse e-mail sans le domaine pour le nom d'utilisateur, vous pouvez configurer un rappel personnalisé pour. La méthode de fabrique a la signature suivante:

Pour des cas d'utilisation simples, on peut utiliser, en supposant que votre attribut email s'appelle   (s'il s'appelle autre chose, changez les deux instances de   en  ):

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.

Exemple:


 * Votre IdP envoie un attribut nommé "groupes" avec une liste de noms tels que "administrateur", "étudiant", "enseignant", ... dans la réponse SAML après authentification.
 * Tous les utilisateurs qui ont la valeur "administrator" dans l'attribut "groups" doivent être mappés au groupe "sysop" de MediaWiki pour leur donner des droits d'administrateur au sein de votre instance de MediaWiki.
 * Créez une carte de groupe dans votre LocalSettings.php comme suit:

Vous pouvez proposer des mappages assez complexes qui correspondent à vos besoins. Si vous avez plusieurs attributs de SAML, ajoutez-les simplement au tableau avec le tableau de valeurs que vous souhaitez mapper.

Si un groupe MediaWiki n'existe pas, il sera créé "à la volée" lors du premier mappage réussi d'un utilisateur.

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 :

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 :

Traitement des données arbitraires de la réponse SAML
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  interface. For convenience the base class  can be used, which has a proper factory callback and constructor implemented. An example

It then needs to be instantiated by using the.

Notes des versions

 * Version 4.5.2
 * fixed bug: Groups are not removed in MW if the attribute is not existing (T246351)
 * Version 4.5.1
 * fixed warning: $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).

Bogues connus
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 phpsession for store.type. This may be due to T147161. To fix this, use a different store type in the configuration of the SimpleSAMLphp software by adjusting simplesamlphp/config/config.php (see 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',