AD FS abzulösen und das Authentifizierungsprotokoll einer Anwendung zu ändern, sind zwei getrennte Entscheidungen. Eine Anwendung, die bereits WS-Federation verwendet, kann dieses Protokoll möglicherweise beibehalten und dennoch zu FoxIDs als vertrauenswürdigem Identity Provider wechseln.
Der erste sinnvolle Meilenstein ist eine Anwendung, die dieselben Benutzer erkennt, die vorgesehenen Zugriffe erlaubt und einen getesteten Rückweg bietet. Eine erfolgreiche Anmeldung allein weist keines dieser Ergebnisse nach.
Dieser Leitfaden richtet sich an IAM- und Lösungsarchitekten, die diese erste Migration vorbereiten. Er behandelt eine browserbasierte Anwendung mit passivem WS-Federation, oft als WS-Fed abgekürzt. Domänenföderation für Microsoft 365, die Anmeldung bei Windows und aktive WS-Trust Clients erfordern eine eigene Bewertung und sind nicht Teil dieses Beispiels.
Anwendungsumstellung und Verzeichnisumstellung trennen
AD FS ist ein Föderationsdienst. Active Directory ist das Verzeichnis, gegen das viele AD FS Installationen authentifizieren. Eine Änderung der Föderations-Vertrauensbeziehung einer Anwendung verschiebt für sich genommen weder Verzeichniskonten noch Passwörter.
Ein mögliches Übergangsmodell behält AD FS zunächst als Authentifizierungsquelle bei:
| Phase | Wem die Anwendung vertraut | Wo sich der Benutzer authentifiziert |
|---|---|---|
| Vorher | AD FS stellt das WS-Federation Token der Anwendung aus | AD FS verwendet seine bestehende Authentifizierungskonfiguration |
| Erstes Pilotprojekt | FoxIDs stellt ein neues WS-Federation Token für die Anwendung aus | FoxIDs leitet den Browser über eine konfigurierte Authentifizierungsmethode zu AD FS |
| Eine spätere, separate Änderung | Die Anwendung vertraut weiterhin FoxIDs | Ein anderer externer Identity Provider oder FoxIDs Login mit Directory Connector für AD ersetzt AD FS nach gesonderter Validierung |
FoxIDs unterstützt sowohl eine WS-Federation Anwendungsregistrierung zur Anwendung hin als auch eine WS-Federation Authentifizierungsmethode zu AD FS hin. Die beiden Seiten haben unterschiedliche Aufgaben: Eine stellt Tokens aus, die andere validiert die Antwort des vorgeschalteten Identity Providers.
Im Pilotprojekt stellt AD FS ein für FoxIDs bestimmtes Token aus. FoxIDs validiert es und stellt ein separates Token für die Anwendung aus. Das alte Token wird also nicht unverändert durchgereicht: Die Anwendung muss dem Aussteller und Signaturzertifikat von FoxIDs vertrauen.
Das Pilotprojekt bleibt von AD FS abhängig. Es schafft einen kontrollierten Punkt, an dem sich die Vertrauensbeziehung und die Claim-Anforderungen der Anwendung prüfen lassen. Der Föderationsdienst wird damit noch nicht außer Betrieb genommen.
Zwei Wege nach AD FS
Nach dem Pilotprojekt sind beide Wege möglich:
- Einen externen Identity Provider beibehalten. Ersetzen Sie AD FS durch einen anderen IdP, der über eine unterstützte Authentifizierungsmethode mit FoxIDs verbunden ist. FoxIDs bleibt der vertrauenswürdige Aussteller der WS-Federation Tokens für die Anwendung. Die Anwendung muss daher nicht das Protokoll des neuen Anbieters übernehmen.
- FoxIDs Login mit Active Directory verwenden. Der Directory Connector für Active Directory validiert Passwörter gegen AD. Dadurch entfällt AD FS im Anmeldepfad dieser Anwendung, während AD das maßgebliche Verzeichnis bleibt. Der Leitfaden zur Modernisierung der Anmeldung mit Active Directory erläutert diese Architektur.
Ein späterer Wechsel zur Passwortvalidierung in FoxIDs ist optional. Erfolgreiche Anmeldungen über den Connector erstellen oder aktualisieren interne FoxIDs Benutzer. Wenn die lokale Passwortspeicherung aktiviert ist, wird zudem ein Passwort-Hash gespeichert, der diese Benutzer auf eine spätere Umstellung vorbereitet. Dies ist eine schrittweise Migration, kein Export aller Konten aus AD. Solange der Connector aktiviert ist, bleibt AD maßgeblich.
Prüfen Sie bei beiden Wegen Kontozuordnungen, Claims, MFA und Abmeldung erneut. Das folgende Pilotprojekt mit der ersten Anwendung ermittelt, was dabei erhalten bleiben muss.
Erfassen, was die erste Anwendung tatsächlich verwendet
Wählen Sie eine Anwendung mit einem Verantwortlichen, einer repräsentativen Testumgebung und einer wiederherstellbaren Konfiguration. Prüfen Sie, ob die Middleware oder der Anbieter einen Wechsel des vertrauenswürdigen STS unterstützt. STS steht für Security Token Service. Eine konfigurierbare Metadaten-URL ist hilfreich, doch auch individuelle Ausstellerprüfungen, Code zur Kontosuche und Autorisierungsregeln sind relevant.
Als Beispiel dient eine fiktive Anwendung zur Auslagenerstattung. Die folgende Tabelle veranschaulicht den Zielvertrag. Sie ist weder eine exportierte Konfiguration noch der Bericht einer abgeschlossenen Migration.
| Vertragsbestandteil | Bestehendes Verhalten | Erforderliches Ergebnis im Pilotprojekt |
|---|---|---|
| Realm / Audience | urn:example:expenses identifiziert die Anwendung |
Der wtrealm der Anwendung stimmt mit ihrer Registrierung in FoxIDs überein, und das Token ist für diese Anwendung bestimmt |
| Reply URL | Die Testinstanz empfängt Antworten unter https://expenses-test.example.org/signin-wsfed |
Nur der vorgesehene Test-Callback wird akzeptiert und verwendet |
| Vertrauenswürdiger Aussteller und Signaturschlüssel | Die Anwendung vertraut den Metadaten und Signaturschlüsseln von AD FS | Die Testinstanz vertraut den für dieses Pilotprojekt ausgewählten Metadaten, dem Aussteller und den Signaturschlüsseln von FoxIDs |
| Tokenformat | Die Middleware akzeptiert SAML 1.1 innerhalb von WS-Federation | Das Tokenformat bleibt erhalten, sofern keine gesondert getestete Änderung erforderlich ist |
| Kontosuche | Der Claim NameIdentifier der Anwendung identifiziert den Mitarbeiter E1042 |
Dasselbe bestehende Konto und dessen Historie werden ausgewählt; es entsteht kein zweites Konto |
| Autorisierung | Die Rolle ExpenseApprover erlaubt die Freigabe |
Berechtigte Benutzer behalten die Berechtigung; Benutzer ohne diese Rolle können weiterhin keine Freigabe erteilen |
| Sitzungsverhalten | Die Anwendung hat ein lokales Cookie und eine definierte Abmelderichtlinie | Anmeldung, Ablauf, erneute Authentifizierung und Abmeldung entsprechen über den neuen Pfad der vereinbarten Richtlinie |
Verwenden Sie beim Ausfüllen der Tabelle die Werte und Claim-Typen der tatsächlichen Anwendung. Prüfen Sie, ob die Kontosuche auch den Token-Aussteller oder den Namen des externen Anmeldeanbieters berücksichtigt. Die sichtbare Benutzer-ID allein zu erhalten, reicht möglicherweise nicht aus, um die Kontozuordnung beizubehalten.
FoxIDs kann SAML 1.1 oder SAML 2.0 Tokens über WS-Federation ausstellen. SAML 1.1 ist der Standard. Ein SAML 2.0 Token innerhalb einer WS-Federation Antwort bedeutet keinen Wechsel zum Protokoll SAML 2.0 Web SSO. Entscheiden Sie über Protokoll und Tokenformat getrennt.
Dokumentieren Sie neben dem Vertrauen in die Signaturschlüssel auch Verschlüsselungsanforderungen und Zertifikatsablaufdaten. Verschlüsselung und Signaturvalidierung lösen unterschiedliche Probleme. Die Unterstützung muss zur empfangenden Anwendung passen. Für ASP.NET Core nennt Microsofts Leitfaden zur WS-Federation Middleware MetadataAddress, Wtrealm und die Callback-Konfiguration als relevante Integrationseinstellungen. Prüfen Sie Ihre tatsächliche Middleware und Version, bevor Sie ein Konfigurationsbeispiel übernehmen.
Beide Seiten in einer Testumgebung konfigurieren
Richten Sie das Pilotprojekt in einer separaten FoxIDs Umgebung ein und verwenden Sie eine Testinstanz der Anwendung. Konfigurieren Sie die Verbindung zu AD FS als Authentifizierungsmethode. Registrieren Sie anschließend die bestehende Anwendung in FoxIDs mit Realm, Reply URL, Tokentyp und den erforderlichen Claims.
Auf der Seite von AD FS ist FoxIDs eine eigenständige Relying Party. Richten Sie diese Vertrauensbeziehung anhand der Metadaten der FoxIDs Authentifizierungsmethode ein und definieren Sie die Claims und Zugriffsrichtlinie, die AD FS darauf anwenden soll. Halten Sie die ursprüngliche Vertrauensbeziehung der Anwendung zu AD FS während des vereinbarten Rollback-Zeitfensters verfügbar.
Gehen Sie nicht davon aus, dass die Claim-Regeln, Zugriffsbeschränkungen oder MFA-Richtlinien der ursprünglichen Relying Party automatisch für die neue Vertrauensbeziehung gelten. AD FS Claim-Regeln sind einzelnen Vertrauensbeziehungen zugeordnet, wie Microsoft in seiner Dokumentation zu Claim-Regeln beschreibt. Stellen Sie das erforderliche Verhalten an der passenden Stelle wieder her und testen Sie es.
Konfigurieren Sie anschließend die Testinstanz der Anwendung für die STS-Metadaten von FoxIDs und den erwarteten Aussteller. Lassen Sie die Validierung von Aussteller, Audience und Signatur aktiviert. Verwenden Sie die für die tatsächliche Umgebung erzeugten Endpunkte, statt eine AD FS URL manuell anzupassen.
Das passive Pilotprojekt im Browser benötigt die separate Option Microsoft Entra ID Windows sign-in nicht. Diese Funktion unterstützt ein anderes Szenario mit Domänenföderation und aktiven Clients.
Claims bis zur Anwendung verfolgen
Metadaten legen Endpunkte und Vertrauensinformationen fest. Sie bestimmen nicht, wie die Anwendung Konten zuordnet oder Berechtigungen vergibt.
Bei einer vorgeschalteten WS-Federation Methode empfängt FoxIDs SAML Claims, bildet sie intern als JWT Claims ab und wandelt sie für das Token der Anwendung wieder in SAML Claims um. Die Standardzuordnung wandelt beispielsweise http://schemas.microsoft.com/ws/2008/06/identity/claims/role intern in role und für WS-Federation wieder in den SAML Claim-Typ um. Nehmen Sie den erforderlichen SAML Claim-Typ für die Rolle sowohl in Forward claims der Authentifizierungsmethode als auch in Issue claims der Anwendung auf. Rollen gehören nicht zum standardmäßigen Claim-Satz.
Kennungen erfordern eine separate Prüfung. Bei einer WS-Federation Authentifizierungsmethode namens adfs versieht FoxIDs die eingehende Kennung E1042 vor nachfolgenden Claim-Transformationen mit einem Präfix: adfs|E1042. Erwartet die Auslagenanwendung E1042, definieren Sie eine ausdrückliche Zuordnung, die die bestehende Kontoverknüpfung erhält. Entfernen Sie Präfixe nicht pauschal: Identische Kennungen aus unterschiedlichen Quellen könnten sonst dasselbe Konto auswählen.
Vergleichen Sie einen bisherigen Genehmiger mit einem Mitarbeiter, der keine Auslagen freigeben darf. Untersuchen Sie die Claims, die die Anwendung tatsächlich verwendet, einschließlich etwaiger Zuordnungen in der Middleware, und testen Sie die resultierenden Berechtigungen. Claim-Transformationen können Namen und Werte ändern. Prüfen Sie daher die endgültige Ausgabe, nicht nur die Konfiguration.
Verwenden Sie für Implementierungsdetails die Dokumentation zu Claim-Transformationen und Zuordnungen. Leiten Sie die von der Anwendung benötigten Claims weiter und stellen Sie diese aus. Ein Platzhalter ersetzt nicht die Entscheidung darüber, welche Daten die Anwendung erhalten soll.
Zugriff und Verweigerung vor der Umstellung testen
Vereinbaren Sie vor den Tests die erwarteten Ergebnisse mit dem Anwendungsverantwortlichen. Dokumentieren Sie sowohl die beobachteten Tokens/Claims als auch das Anwendungsverhalten. Verwenden Sie Testkonten und halten Sie Authentifizierungsmaterial aus gemeinsam genutzten Berichten heraus.
| Test | Erforderlicher Nachweis vor dem nächsten Schritt |
|---|---|
| Ein bestehender Benutzer meldet sich an | Das bestehende Anwendungskonto mit seinen Daten und seiner Historie wird ausgewählt |
| Ein Genehmiger und ein gewöhnlicher Mitarbeiter führen dieselbe Aktion aus | Der Genehmiger ist erfolgreich; dem gewöhnlichen Mitarbeiter wird die Aktion verweigert |
| Ein Benutzer ist durch die Zugriffsrichtlinie der alten Anwendung ausgeschlossen | Auch der neue Pfad verweigert diesem Benutzer den Zugriff |
| MFA ist erforderlich, auch bei einer bestehenden Browsersitzung mit AD FS | Der konfigurierte Ablauf erfüllt das geforderte Sicherheitsniveau; eine erfolgreiche Anmeldung beim vorgeschalteten Anbieter allein gilt nicht als ausreichender Nachweis |
| Der Benutzer meldet sich ab und ruft erneut eine geschützte Seite auf | Anwendungscookie, Sitzung bei AD FS und konfigurierter Abmelde-/Cleanup-Ablauf erfüllen die vereinbarte Abmelderichtlinie |
| Ein neuer Authentifizierungsversuch benötigt AD FS, während AD FS nicht verfügbar ist | Der Versuch schlägt fehl, ohne die erforderliche Authentifizierungsquelle zu umgehen; der Betriebsverantwortliche kann den Fehler erkennen |
| Testantworten enthalten einen ungültigen Aussteller, eine ungültige Audience oder Signatur | Jede ungültige Antwort wird abgewiesen; die Validierung bleibt aktiviert |
| Die vorherige Anwendungskonfiguration wird wiederhergestellt | Eine neue Anmeldung über den ursprünglichen AD FS Pfad wählt das richtige Konto und die richtigen Berechtigungen aus |
Testen Sie Sitzungsablauf und erneute Authentifizierung getrennt von einer gewöhnlichen erfolgreichen Anmeldung. Ein deaktiviertes Konto oder ein Benutzer mit entfernter Rolle kann weiterhin eine bestehende Anwendungssitzung haben. Vereinbaren Sie, wann der Zugriff enden muss, und prüfen Sie diesen Zeitpunkt. Gehen Sie nicht davon aus, dass eine neue Föderationskonfiguration sämtliche Cookies ungültig macht.
FoxIDs unterstützt WS-Federation Abmeldung und Cleanup-Benachrichtigungen, wenn diese konfiguriert sind. Ob jede beteiligte Anwendung ihre lokale Sitzung beendet, hängt von ihrer Implementierung und dem tatsächlichen Browser-Ablauf ab. Prüfen Sie das Abmeldeverhalten mit den Clients und Browsern, die in Produktion verwendet werden.
Die Umstellung klein und umkehrbar halten
Dokumentieren Sie vor dem Produktionseinsatz, wer die vorherige Anwendungskonfiguration wiederherstellen kann, wo sie liegt und welche Feststellungen einen Rollback auslösen. Falsche Kontozuordnungen, unbeabsichtigte Berechtigungen und nicht erfüllte MFA-Anforderungen sollten den Rollout sofort stoppen. Vereinbaren Sie Schwellenwerte für Anmeldefehler und Betriebsstörungen vorab, statt sie während der Änderung festzulegen.
Führen Sie die vereinbarte Anwendungsumstellung in einem überwachten Zeitfenster durch. Ein Pilotprojekt mit einzelnen Benutzern ist nur möglich, wenn die Anwendung und das Routing-Konzept dies unterstützen. Verwenden Sie andernfalls zunächst die Testinstanz und behandeln Sie die Produktionsanwendung als Umstellungseinheit.
Ein Rollback muss mehr als die Metadaten-URL umfassen. Stellen Sie das bisherige Vertrauen in Aussteller und Schlüssel, die Claim-Konfiguration und alle während des Pilotprojekts geänderten Kontozuordnungen wieder her. Legen Sie fest, wie Sitzungen über den neuen Pfad beendet oder ersetzt werden. Die Wiederherstellung des alten Endpunkts macht Änderungen an Anwendungsdaten nicht rückgängig und entfernt diese Sitzungen nicht automatisch.
Wenn diese Anwendung stabil läuft, entscheiden Sie, welche Abhängigkeit als Nächstes entfallen soll. Die Ablösung des vorgeschalteten AD FS, der Wechsel des Anwendungsprotokolls zu OpenID Connect und die Migration von Verzeichnisbenutzern sind separate Folgeänderungen mit jeweils eigenen Tests. Falls sich die Speicherung von Benutzern oder Passwörtern ändern soll, nutzen Sie den Entscheidungsleitfaden zur Passwortmigration, statt diese Arbeit in das Pilotprojekt aufzunehmen.
Das gemessene Ergebnis der ersten Anwendung liefert der nächsten Migration einen konkreten Ausgangspunkt: eine verstandene Vertrauenskonfiguration, geprüftes Benutzer- und Zugriffsverhalten sowie ein vom Team erprobtes Wiederherstellungsverfahren. Nutzen Sie den Migrationsleitfaden, um diese Erkenntnisse in den umfassenderen Plan zu überführen.