Self-hosted Duende verlassen: was migriert wird und was Sie nicht mehr betreiben

Duende IdentityServer ist eine wirklich gute Software: Wenn Sie Ihre Identitätsebene von Anfang bis Ende selbst besitzen wollen, ist sie in .NET der Standard. Aber genau dieses "Besitzen" ist der ganze Kostenpunkt: Sie hosten sie, patchen sie, skalieren sie und bauen alles drumherum selbst, die Admin-Oberfläche, MFA, Audit-Logs, Branding, eine Statusseite, Benutzer- und Rollenverwaltung. Irgendwann entscheidet ein Team, dass es lieber keinen IdP betreiben möchte, und die einzige Frage, die zählt, ist, wie schmerzhaft der Wechsel ist. Hier ist, was tatsächlich migriert wird.

Was Sie eigentlich betreiben

Self-Hosting von Duende bürdet Ihnen mehr auf als nur die Token-Endpunkte:

• Der IdP selbst: Hosting, Skalierung, Patching und die Lizenz (SAML ist ein kostenpflichtiges Add-on obendrauf).
• Alles drumherum, das Sie selbst gebaut haben: Admin-Portal, MFA-Registrierung, Audit-Logging, individuelles Branding, eine Statusseite, Benutzer- und Rollenverwaltung.

In die zweite Liste fließt normalerweise die meiste Zeit.

Was migriert wird, und das ist größtenteils mechanisch

Duende hält seine Konfiguration in SQL (der ConfigurationDb) und seine Benutzer in ASP.NET Identity. Eine Migration liest beide aus:

• Clients → OAuth-Clients, einschließlich Redirect- und Logout-URIs, CORS-Ursprünge, Grant-Typen, Verwendungs-/Ablaufsemantik von Refresh-Tokens und Device-Code-Lebensdauern. Deaktivierte Clients werden deaktiviert importiert; abgelaufene Secrets werden mit einer Warnung übersprungen.
• Scopes → ApiScopes und IdentityResources werden direkt zugeordnet. Die ApiResource-Zwischenschicht von Duende (eine Audience plus eine gemeinsame Claims-Liste) wird auf das einfachere Modell heruntergebrochen: Der Ressourcenname wird zur Audience bei jedem Client, der einen zugehörigen Scope verwendet, und seine Claims werden mit diesen Scopes zusammengeführt.
• Benutzer → die gute Nachricht: Passwort-Hashes von ASP.NET Identity V3 (und älteres bcrypt) werden nativ verifiziert und beim ersten Anmelden neu gehasht. Keine Passwort-Resets, kein Support-Ticket, nichts, das Ihre Benutzer bemerken. (Das ist der Teil, der beim Verlassen von Auth0 wirklich schwierig ist, mit Duende funktioniert es einfach, weil es dasselbe Hashing ist, das Ihre App bereits verwendet.)
• Rollen und Zuweisungen, externe Logins und OIDC-Identitätsanbieter kommen alle mit. SAML-Anbieter werden für Sie markiert, damit Sie sie auf der anderen Seite neu konfigurieren können.

Der Aspekt der Identitätsstabilität

Wie bei jedem IdP-Wechsel besteht das Wichtige darin, die Benutzer-sub oder client_id nicht zu ändern: Nachgelagerte Refresh-Tokens, SCIM-Einträge in den IdPs der Kunden und in Ihrer eigenen Datenbank gespeicherte Benutzer-IDs verweisen alle darauf. Der Importer bewahrt beide. Und falls einer Ihrer Portal-Owner auch als Duende-Benutzer unter einer anderen ID existiert, gleicht er sie ab (durch Rotation auf die Duende-sub) in gestaffelten, wiederherstellbaren Schritten, statt einen halb migrierten Owner zu hinterlassen, der sich nicht anmelden kann.

Ein Hinweis zum Testen von Migrationen (eine .NET-Falle)

Wir testen den Importer gegen eine echte, mit Daten befüllte Duende-Datenbank, nicht gegen Mocks, und das hat sich ausgezahlt. ASP.NET Identity speichert AspNetUsers.LockoutEnd als datetimeoffset, und das Auslesen mit reader.GetDateTime() wirft bei diesem Typ eine InvalidCastException. Ein einziger gesperrter Benutzer hätte also den gesamten Benutzer-Import scheitern lassen. Das findet man nur, indem man den Importer gegen echte Daten laufen lässt, in denen ein gesperrter Benutzer enthalten ist. Wenn Sie ein Migrations-Tool abwägen, ist das die Frage, die sich zu stellen lohnt: Wird es gegen eine befüllte Datenbank getestet oder nur gegen die Quell-API gemockt?

Was Sie nicht mehr tun müssen

Der Sinn des Wechsels ist nicht die Migration, sondern alles danach. SAML, SCIM, MFA, Audit-Logs, eigene Domains und Branding sind enthalten, statt Dinge zu sein, die Sie bauen und betreiben, und das Patchen und Skalieren des IdP ist nicht mehr Ihr Problem. Wenn das Self-Hosting von Duende eine bewusste Entscheidung war ("wir wollen volle Kontrolle") und das immer noch gilt, dann bleiben Sie dabei, das ist eine völlig gute Wahl. Das hier ist für den Fall, dass der Betrieb eines IdP nicht mehr dort ist, wo Sie Ihre Zeit verbringen möchten.

Falls Sie es in Erwägung ziehen

Die Migration ist größtenteils mechanisch, Passwörter werden ohne Resets übernommen, und die Vorschau ist schreibgeschützt: Richten Sie sie auf Ihre Duende-Datenbank, und sie zeigt Ihnen genau, was importiert würde, bevor irgendetwas geschrieben wird.

→ Von Duende migrieren