Identity & Access Management

Von SAML zu OIDC migrieren, ohne den Betrieb anzuhalten

Ein Stichtagswechsel ist bei Identity-Migrationen selten notwendig – und fast immer riskanter als ein geplanter Parallelbetrieb.

Schematische Darstellung eines Parallelbetriebs während einer Migration: eine Anwendung nutzt weiterhin SAML, eine weitere bereits OpenID Connect, beide gegen denselben Identity-Dienst mit angebundenem Verzeichnisdienst
KI-Hinweis: Bild mit KI erstellt © EicDevCon UG (haftungsbeschränkt)

Der Wunsch nach einem Stichtag ist verständlich: ein Wochenende, eine Umstellung, danach ist alles neu. In der Praxis bedeutet er, dass sämtliche Fehler gleichzeitig auftreten – und zwar bei allen Anwendungen auf einmal.

Warum Parallelbetrieb die günstigere Option ist

SAML und OpenID Connect können nebeneinander gegen denselben Identity-Dienst laufen. Eine Anwendung wird umgestellt, beobachtet und erst dann die nächste. Fällt etwas auf, betrifft es genau eine Anwendung.

Entscheidung

Parallelbetrieb kostet Zeit im Projektplan und spart sie im Vorfall. Ein Stichtagswechsel tauscht diese beiden Posten.

Was vorher geklärt sein muss

Die führende Quelle für Benutzer. Wenn das Verzeichnis die Wahrheit ist, ändert die Migration nur das Protokoll. Ist es das nicht, ist die Migration der falsche Zeitpunkt, das zu bemerken.

Das Rollenmodell. SAML-Attribute und OIDC-Claims sind nicht dasselbe. Die Zuordnung muss explizit erfolgen und nicht implizit über gleichlautende Namen.

Abmeldeverhalten. Single Logout verhält sich in beiden Protokollen unterschiedlich. Wer das erst nach der Umstellung prüft, erklärt es anschließend dem Support.

Attribute sauber abbilden

Die Zuordnung von Verzeichnisattributen auf Claims gehört dokumentiert – nicht nur konfiguriert:

Verzeichnis SAML-Attribut OIDC-Claim
uid NameID preferred_username
mail emailAddress email
memberOf Group groups

Hinweis

Ein Claim, der in der einen Anwendung groups und in der anderen roles heißt, ist kein Detail. Er ist die häufigste Ursache für „funktioniert bei mir, aber nicht dort“.

Reihenfolge in der Praxis

  1. Identity-Dienst so konfigurieren, dass beide Protokolle bedient werden.
  2. Eine unkritische Anwendung auf OIDC umstellen und im Betrieb beobachten.
  3. Attributzuordnung anhand der realen Tokens prüfen, nicht anhand der Dokumentation.
  4. Weitere Anwandungen einzeln nachziehen.
  5. SAML-Clients erst deaktivieren, wenn nachweislich keine Anmeldungen mehr darüber laufen.

Aus der Praxis

Schritt 5 wird regelmäßig übersprungen. Ein Blick in die Anmeldeprotokolle des Identity-Dienstes beantwortet in einer Minute, ob eine Anwendung wirklich umgestellt ist.

Einordnung

Migrationen dieser Art berühren Betrieb, Berechtigungen und Anwendungsentwicklung gleichzeitig. Das Arbeitsfeld Identity & Access Management beschreibt, wie diese Bereiche zusammenhängen.