SSO MediaWiki : LDAP, OAuth2/OIDC et gestion des accès (guide 2026)

MediaWiki + SSO : l’objectif (et ce que ça ne fait pas)

Un SSO sur MediaWiki sert à centraliser l’identité : l’utilisateur se connecte via votre fournisseur (Keycloak, Azure AD, Google Workspace, GitHub, Active Directory…).

Ce que le SSO ne remplace pas :

les permissions MediaWiki (groupes, protections de pages, droits d’édition)
la gouvernance (qui a accès à quoi, qui est admin, qui peut créer des comptes)

L’idée saine : identité côté IdP, droits fins côté MediaWiki, avec synchronisation de groupes si besoin.

Schéma du flux SSO (MediaWiki ↔ IdP)

Si vous n’avez pas encore déployé votre wiki proprement en prod, commencez par :

Quel type de SSO choisir ? (OIDC/OAuth2 vs LDAP)

Option A — OIDC / OAuth2 (recommandée dans la majorité des cas)

C’est le choix le plus simple quand vous avez déjà un IdP moderne (Keycloak, Azure AD, Google, GitHub, etc.). Avantages :

parcours de connexion fluide
MFA/2FA géré côté IdP
rotation des secrets et politiques centralisées
possibilité de synchroniser des groupes

Option B — LDAP / Active Directory

Utile si votre SI est très orienté AD/LDAP (intranet, comptes Windows) et que vous voulez authentifier directement sur l’annuaire. Avantages :

s’intègre bien à AD
mapping attributs (mail, nom complet, identifiant)

Dans les deux cas, la base est la même : PluggableAuth, qui sert de “cadre” d’authentification externe.

Pré-requis rapides (à vérifier avant de toucher la config)

Wiki accessible en HTTPS (indispensable dès qu’il y a redirection d’auth)
Accès admin au serveur (ou conteneur) MediaWiki
Extensions installées proprement (idéalement via Composer quand requis)

Pour un wiki privé, vous voudrez aussi maîtriser :

les permissions read pour les anonymes
les pages spéciales à laisser accessibles pour le flux de connexion

Mettre en place un SSO OIDC (Keycloak / Azure AD / autre IdP compatible)

1) Installer PluggableAuth + l’extension OIDC

Le principe :

PluggableAuth gère l’intégration côté MediaWiki
l’extension OIDC fait l’échange avec l’IdP (authorize/code/token)

Dans LocalSettings.php :

wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'OpenIDConnect' );

// Option : si vous voulez éviter le login local
$wgPluggableAuth_EnableLocalLogin = false;

2) Déclarer le client côté IdP

Côté Keycloak/Azure AD, vous créez un client “confidentiel” avec :

une Redirect URI de type .../wiki/Special:PluggableAuthLogin (selon votre extension/config)
un client ID et un secret
des scopes minimaux (souvent openid email profile)

3) Définir le bouton de connexion et la config

Exemple (à adapter selon l’extension OIDC installée) :

$wgPluggableAuth_Config = [
  'Se connecter avec le SSO' => [
    'plugin' => 'OpenIDConnect',
    'data' => [
      'providerURL' => 'https://idp.example.com/realms/acme',
      'clientID' => 'mediawiki',
      'clientsecret' => 'CHANGE_ME',
      'preferred_username' => 'email'
    ]
  ]
];

// Nécessaire pour créer/associer des comptes
$wgGroupPermissions['*']['autocreateaccount'] = true;

Astuce : pour la gouvernance et la protection, gardez aussi ce guide à portée :

Sécuriser MediaWiki (permissions, anti-spam, WAF)

Variante OAuth2 “classique” (Google / GitHub / Keycloak, etc.)

Si votre IdP est très standard OAuth2, une approche fréquente est :

OAuth2 Client (consommateur OAuth2)
WSOAuth au-dessus de PluggableAuth (intégration et, selon les cas, synchronisation de groupes)

Exemple minimal (conceptuel) :

wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'WSOAuth' );
wfLoadExtension( 'MW-OAuth2Client' );

Sur un wiki privé, il faut souvent laisser accessibles certaines pages spéciales, sinon la redirection est bloquée (login impossible).

Wiki privé : rendre le flux de connexion possible (sans ouvrir le contenu)

Si votre wiki n’est pas lisible par les anonymes, vous pouvez :

$wgGroupPermissions['*']['read'] = false;

$wgWhitelistRead = [
  'Special:Userlogin',
  'Special:PluggableAuthLogin',
  'Special:OAuth2Client',
  'Special:OAuth2Client/callback',
  'Main Page',
];

Le bon compromis : contenu privé, mais pages techniques du flux d’auth accessibles.

Groupes et droits : comment garder un modèle simple et robuste

Stratégie conseillée

Gardez peu de groupes côté MediaWiki (ex : editor, admin)
Synchronisez seulement les groupes nécessaires (éviter la “pollution” par des dizaines de rôles métiers)
Conservez les protections de pages et droits spécifiques dans MediaWiki

Pour la performance et la stabilité, ayez aussi un œil sur :

Performance MediaWiki (cache, DB, index, CDN)

Gestion des accès : points clés

Mettre en place une auth LDAP / Active Directory (PluggableAuth + LDAPAuthentication2)

Côté LDAP, la voie classique est :

LDAPProvider (base)
LDAPAuthentication2 (auth)
PluggableAuth (framework)

Dans LocalSettings.php :

wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'LDAPProvider' );
wfLoadExtension( 'LDAPAuthentication2' );

$LDAPProviderDomainConfigs = "$IP/../ldapprovider.json";

$wgPluggableAuth_EnableLocalLogin = false;
$LDAPAuthentication2AllowLocalLogin = false;

$wgPluggableAuth_Config['Se connecter (AD)'] = [
  'plugin' => 'LDAPAuthentication2',
  'data' => [ 'domain' => 'myad' ]
];

L’intérêt : vous mappez des attributs annuaire (email, nom complet, identifiant) et vous gardez la gestion des droits MediaWiki claire.

Problèmes fréquents (et comment les éviter vite)

Redirect URI incorrecte : l’IdP refuse, ou boucle. Vérifiez l’URL complète, et que le wiki est bien en HTTPS.
Wiki privé trop strict : si les pages spéciales ne sont pas autorisées, la connexion échoue avant même la redirection.
Création de compte bloquée : sans autocreateaccount (ou un workflow adapté), le premier login ne peut pas créer le compte local.
Nom d’utilisateur non conforme : selon l’IdP, certaines valeurs (email) peuvent contenir des caractères à gérer.