Accueil > OpenID Connect OAuth Server par DnC > Développer > Utiliser SPIP comme pourvoyeur d’identité d’OIDC

Utiliser SPIP comme pourvoyeur d’identité d’OIDC

De nombreuses applications avancées peuvent être construites en intégrant un serveur OIDC dans un gestionnaire de contenu (Content Management System, CMS) ou un framework. Soit que le CMS serve d’hôte pour développer l’environnement de gestion du serveur OIDC, soit que l’authentification serve, par exemple, à construire un système de distribution d’applications en tant que service (Software as Service, SaaS).
Chez DnC, nous utilisons le CMS SPIP pour ces deux approches, et d’autres applications encore [1].
Cependant, il existe une difficulté : le CMS possède déjà son propre système d’identification des utilisateurs (les ’auteurs’), comment éviter de doublonner avec les utilisateurs finaux enregistrés sur le serveur OIDC ?

Synchroniser les tables ’auteurs’ et ’users’ ou se passer de la table ’users’ ?

En l’état nous avons deux tables : ’users’ pour OIDC et ’auteurs’ pour SPIP. Le problème à résoudre est donc d’unifier les données.
Deux solutions sont possibles :
- la mauvaise : assurer la synchronisation de la table ’users’ à partir de données de la table ’auteurs’ de SPIP : tout enregistrement de données sur la table ’auteurs’ est répercuté sur la table ’users’, et vice-et-versa.
- la bonne : utiliser uniquement les données de SPIP.

Utiliser SPIP comme pourvoyeur d’identité

Dans cette deuxième solution, les données de SPIP sont utilisées pour réaliser la fonction d’identification du serveur OIDC. Cela nécessite donc un nouveau module d’identification ’spip’ comprenant des scripts login.php et login_return.php qui utiliseront les données de la table auteurs de SPIP.

Et le serpent se mord la queue...

Une fois le serveur OAuthSD intégré à SPIP comme indiqué, il peut non seulement être utilisé pour l’authentification des utilisateurs d’applications tierces ou l’accès aux ressources protégées (ce pour quoi est fait un serveur OIDC), mais également pour authentifier les utilisateurs (auteurs) de SPIP en se substituant au module d’authentification standard de ce CMS.

Quelques restrictions

Nous avons l’expérience du fonctionnement du serveur OAuthSD avec une table ’users’ vide, par exemple l’utilisation de Kerberos ou d’Aramis comme pourvoyeurs d’identité.

Sans modification du serveur OAuthSD, ceci implique seulement quelques restrictions des fonctionnalités du serveur OIDC (dont nous n’aurons généralement pas besoin) :
- La ré-identification avec id_token_hint ne peut fonctionner,
- le contrôleur UserInfo ne peut fonctionner sous sa forme standard et doit être modifié.

Les modules d’identification secondaires (TFA) devront également être modifiés pour s’appuyer sur les données de la table ’auteurs’ de SPIP.

Notes

[1Cet article est le premier d’une série à venir qui développera l’intégration d’un serveur OIDC dans SPIP et les usages qui peuvent en être faits.