Migration

Die Migration zu FoxIDs kombiniert normalerweise Anwendungsmigration, Benutzermigration und einen kontrollierten Übergang zwischen der vorhandenen Identitätsplattform und FoxIDs. Planen Sie diese Arbeitsabläufe gemeinsam, damit Bezeichner, Claims, Authentifizierungsverhalten und Rollback-Optionen während des gesamten Übergangs konsistent bleiben.

FoxIDs Mandanten unterstützen separate Umgebungen. Nutzen Sie dedizierte Entwicklungs-, Test-, Staging- und Produktionsumgebungen, um Migrationsabläufe parallel zu konfigurieren und zu validieren, ohne die Produktionsumgebung vorzeitig zu ändern.

Bewerten Sie die vorhandene Identitätsplattform

Beginnen Sie mit der Aufnahme:

Anwendungen, APIs und Umgebungen, die mit der vorhandenen Plattform verbunden sind.
OpenID Connect-, OAuth 2.0-, SAML 2.0- und WS-Federation-Konfigurationen.
Identitätsanbieter, Authentifizierungsmethoden und Anforderungen an die Multi-Faktor-Authentifizierung.
Benutzerkennungen, Profile, Claims, Gruppen, Rollen und Zugriffszuweisungen.
Auf der Quellplattform verfügbare Optionen zum Speichern, Validieren und Zurücksetzen von Passwörtern.
Zertifikate, Metadaten, Weiterleitungs-URLs, Abmeldeverhalten und Token-Lebensdauer.
Überwachungs-, Audit- und Rollback-Anforderungen für die Umstellung.

Die Quelle kann AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID oder ein anderer Identitätsanbieter oder ein benutzerdefiniertes Benutzer-Repository sein. Der verfügbare Migrationspfad hängt von den Protokollen, Exportfunktionen und Passwortvalidierungsoptionen ab, die von dieser Quelle bereitgestellt werden.

Anwendungsmigration

Migrieren Sie Anwendungen nach Protokoll und Umgebung, anstatt den Bestand als einzelne Umstellung zu behandeln.

Registrieren Sie die Anwendung in einer nicht produktiven FoxIDs Umgebung.
Reproduzieren Sie die erforderlichen Claims, Bereiche, Identifikatoren, Zertifikate und das Abmeldeverhalten.
Verbinden Sie den vorhandenen Identitätsanbieter als Authentifizierungsmethode, wenn eine parallele Authentifizierung erforderlich ist.
Testen Sie den vollständigen Anmelde-, Token- und Abmeldefluss mit repräsentativen Benutzern und Integrationen.
Verschieben Sie jeweils eine kontrollierte Gruppe oder jeweils eine Anwendung, bevor Sie sie umfassender einführen.

FoxIDs Protokollüberbrückung ermöglicht es einer Anwendung, ihr aktuelles Protokoll beizubehalten, während sich die Seite des Identitätsanbieters ändert. Dies ist nützlich, wenn moderne OpenID Connect-Anwendungen und vorhandene SAML 2.0- oder WS-Federation-Anwendungen im selben Migrationszeitraum betrieben werden müssen.

Benutzerprofile und Identifikatoren

Entscheiden Sie, welche Kennung stabil bleibt, bevor Sie Benutzer importieren oder erstellen. E-Mail-Adressen, Telefonnummern und Benutzernamen können sich ändern. Verwenden Sie daher eine stabile Quellenkennung, sofern die Integration dies unterstützt.

Ordnen Sie die nach der Migration erforderlichen Benutzerinformationen zu:

Benutzerprofileigenschaften und Anmeldekennungen.
Von Anwendungen und APIs verwendete Claims.
Gruppen, Rollen und Zugriffszuweisungen.
Anforderungen an die Multi-Faktor-Authentifizierung und der Registrierungs- oder Wiederherstellungsansatz nach der Migration.
Deaktivierte, gelöschte oder anderweitig eingeschränkte Konten.

Verwenden Sie Laden Sie viele Benutzer hoch, wenn Benutzer stapelweise exportiert und importiert werden können. Verwenden Sie Directory Connector, wenn ein vorhandenes Verzeichnis oder benutzerdefiniertes Repository während des Übergangs autorisierend bleiben soll. Verwenden Sie für Active Directory Directory Connector for Active Directory.

Passwortstrategie

Wählen Sie den Passwortpfad basierend auf dem, was die Quellplattform sicher offenlegen oder validieren kann:

Importieren Sie Passwörter oder unterstützte Passwort-Hashes nur, wenn sie in kompatibler Form vorliegen und sicher gehandhabt werden können.
Validieren Sie das vorhandene Passwort über Directory Connector, während das Quellverzeichnis autorisierend bleibt.
Standardmäßig speichert FoxIDs nach erfolgreicher Directory Connector-Validierung eine lokale Kennwortkopie. Dadurch ist es möglich, den Connector später zu deaktivieren und die Passwortvalidierung auf FoxIDs zu verschieben, ohne dass jeder Benutzer einen Reset durchführen muss.
Deaktivieren Sie die lokale Kennwortkopie, wenn die Richtlinie erfordert, dass das externe Verzeichnis der einzige Kennwortspeicher bleibt.
Erfordern Sie das Zurücksetzen des Passworts, wenn das Importieren oder Beibehalten des vorhandenen Passworts technisch nicht möglich ist oder wenn das Zurücksetzen die sicherere Option ist.

Gehen Sie niemals davon aus, dass Passwörter direkt von einem Identitätsanbieter übertragen werden können. Bestätigen Sie das Exportformat, den Hashing-Algorithmus, die Validierungs-API und die Sicherheitseinschränkungen der Quellplattform, bevor Sie die Migrationsmethode auswählen.

Schrittweise Migration

Wenn das Quellverzeichnis die Online-Validierung unterstützt, können Benutzer bei ihrer ersten erfolgreichen Anmeldung über Directory Connector in FoxIDs erstellt oder aktualisiert werden. Dies unterstützt einen schrittweisen Übergang, ohne dass alle Benutzer gleichzeitig migrieren müssen.

Halten Sie die Quelle verfügbar, bis die erforderliche Benutzerpopulation migriert und das Rollback-Fenster geschlossen wurde. Überwachen Sie während des Übergangs fehlgeschlagene Anmeldungen, Bezeichnerkonflikte, fehlende Claims und Connector-Verfügbarkeit.

Umstellung und Rollback

Vor der Produktionsumstellung:

Führen Sie repräsentative Anwendungs- und Benutzerakzeptanztests durch.
Bestätigen Sie Zertifikate, Metadaten, DNS, Weiterleitungs-URLs und Firewall-Pfade.
Definieren Sie die Reihenfolge, in der Anwendungen, APIs und Benutzergruppen verschoben werden.
Notieren Sie die vorherige Konfiguration und die Bedingungen, die ein Rollback auslösen.
Stellen Sie sicher, dass die Überwachung und Protokollierung sowohl FoxIDs als auch die verbleibenden Quellplattformflüsse abdeckt.
Kommunizieren Sie das Zurücksetzen von Passwörtern oder ein geändertes Anmeldeverhalten, bevor es sich auf Benutzer auswirkt.

Bei einem schrittweisen Rollout wird die Anzahl der Anwendungen und Benutzer begrenzt, die von jeder Änderung betroffen sind. Halten Sie das Rollback technisch möglich, bis Produktionsverhalten, Claims und Zugriff überprüft wurden.