Quitter Duende auto-hébergé : ce qui migre, et ce que vous cessez d'exploiter

Duende IdentityServer est un logiciel vraiment excellent : si vous voulez posséder votre couche d'identité de bout en bout, c'est la référence en .NET. Mais cette « possession », c'est justement tout le coût : vous l'hébergez, vous la patchez, vous la mettez à l'échelle et vous construisez tout ce qui gravite autour, l'interface d'administration, le MFA, les journaux d'audit, l'image de marque, une page de statut, la gestion des utilisateurs et des rôles. À un moment donné, une équipe décide qu'elle préfère ne pas exploiter d'IdP, et la seule question qui compte est de savoir à quel point la migration est douloureuse. Voici ce qui migre réellement.

Ce que vous exploitez vraiment

Auto-héberger Duende vous rend responsable de bien plus que des points de terminaison de tokens :

• L'IdP lui-même : hébergement, mise à l'échelle, patching et la licence (le SAML est un module payant en supplément).
• Tout ce qui l'entoure et que vous avez construit vous-même : portail d'administration, enrôlement MFA, journalisation d'audit, image de marque personnalisée, une page de statut, gestion des utilisateurs et des rôles.

C'est généralement cette deuxième liste qui consomme le plus de temps.

Ce qui migre, et c'est essentiellement mécanique

Duende conserve sa configuration dans SQL (la ConfigurationDb) et ses utilisateurs dans ASP.NET Identity. Une migration lit les deux :

• Clients → clients OAuth, y compris les URI de redirection et de déconnexion, les origines CORS, les types d'autorisation, la sémantique d'usage et d'expiration des refresh tokens, et les durées de vie des device codes. Les clients désactivés sont importés désactivés ; les secrets expirés sont ignorés avec un avertissement.
• Scopes → les ApiScopes et IdentityResources se mappent directement. La couche intermédiaire ApiResource de Duende (une audience plus une liste de claims partagée) s'aplatit sur le modèle plus simple : le nom de la ressource devient une audience sur chaque client qui utilise un scope membre, et ses claims fusionnent avec ces scopes.
• Utilisateurs → la bonne nouvelle : les hachages de mot de passe d'ASP.NET Identity V3 (et le bcrypt hérité) se vérifient nativement et sont rehachés à la première connexion. Aucune réinitialisation de mot de passe, aucun ticket de support, rien que vos utilisateurs ne remarquent. (C'est la partie réellement difficile quand on quitte Auth0 : avec Duende, ça fonctionne tout simplement, parce que c'est le même hachage que celui que votre application utilise déjà.)
• Les rôles et affectations, les connexions externes et les fournisseurs d'identité OIDC sont tous repris. Les fournisseurs SAML sont signalés pour que vous les reconfiguriez de l'autre côté.

L'aspect stabilité de l'identité

Comme pour tout changement d'IdP, ce qu'il faut bien gérer, c'est de ne pas changer le sub de l'utilisateur ni le client_id : les refresh tokens en aval, les lignes SCIM dans les IdP des clients et les identifiants d'utilisateur stockés dans votre propre base de données y font tous référence. L'importateur préserve les deux. Et si l'un de vos propriétaires de portail existe aussi comme utilisateur Duende sous un identifiant différent, il les réconcilie (en basculant vers le sub Duende) par étapes échelonnées et réversibles, plutôt que de laisser un propriétaire à moitié migré incapable de se connecter.

Une parenthèse sur le test des migrations (un piège .NET)

Nous testons l'importateur contre une vraie base de données Duende alimentée en données, pas contre des mocks, et ça a porté ses fruits. ASP.NET Identity stocke AspNetUsers.LockoutEnd sous forme de datetimeoffset, et le lire avec reader.GetDateTime() lève une InvalidCastException sur ce type. Ainsi, un seul utilisateur verrouillé aurait fait échouer l'import de la totalité des utilisateurs. On ne le découvre qu'en exécutant l'importateur contre des données réelles contenant un utilisateur verrouillé. Si vous évaluez un outil de migration, voilà la question qui mérite d'être posée : est-il testé contre une base de données peuplée, ou simplement mocké contre l'API source ?

Ce que vous cessez de faire

L'intérêt de la migration, ce n'est pas la migration elle-même : c'est tout ce qui vient après. SAML, SCIM, MFA, journaux d'audit, domaines personnalisés et image de marque sont inclus au lieu d'être des choses que vous construisez et exploitez, et le patching et la mise à l'échelle de l'IdP cessent d'être votre problème. Si l'auto-hébergement de Duende était une décision délibérée (« nous voulons un contrôle total ») et qu'elle l'est toujours, restez : c'est un choix parfaitement valable. Ceci s'adresse au moment où exploiter un IdP n'est plus là où vous voulez passer votre temps.

Si vous l'envisagez

La migration est essentiellement mécanique, les mots de passe sont repris sans réinitialisation, et l'aperçu est en lecture seule : pointez-le vers votre base de données Duende et il vous montre exactement ce qui serait importé avant que quoi que ce soit ne soit écrit.

→ Migrer depuis Duende