Von Okta zu FoxIDs migrieren

Stellen Sie Anmeldungen von Okta auf FoxIDs um und wählen Sie den Migrationsweg passend zum Authentifizierungsort jeder Benutzergruppe. Importieren Sie lokale Benutzer und lassen Sie sie ein neues Passwort wählen oder aktivieren Sie passwortlose Anmeldung mit Einmalcodes. Für soziale Anmeldungen und Unternehmensanmeldungen konfigurieren Sie FoxIDs Authentifizierungsmethoden, die externen Identitätsanbietern vertrauen. Okta kann auch während des Wechsels der Anwendungen zu FoxIDs als Identitätsanbieter bestehen bleiben.

Dieser technische Leitfaden behandelt Benutzer in Okta Universal Directory, Anwendungskonfiguration und Kontozuordnung für Okta Identity Engine und Classic Engine.

Für den Import lokaler Benutzer konvertieren Sie den geprüften Okta Export in eine CSV-Datei und laden die Benutzer mit dem FoxIDs Seed Tool gesammelt in FoxIDs. Die folgenden CSV-Beispiele zeigen die Felder für Passworteinrichtung und passwortlose Anmeldung.

Wählen Sie für jede Gruppe einen Ansatz:

Zielumgebung und Anwendung vorbereiten

In einer eigenen Testumgebung können Sie die Migration mit einer kleinen Benutzergruppe vor dem Produktivbetrieb ausprobieren. Die Konfigurationsschritte sind:

1. Wenn Sie eine benutzerdefinierte Domain verwenden möchten, konfigurieren und verifizieren Sie diese beim Mandanten, bevor Sie Anwendungen und externe Identitätsanbieter konfigurieren. Verwenden Sie die daraus entstehenden FoxIDs URLs während der gesamten Migration. Eine spätere Domainänderung erfordert die Aktualisierung externer Konfigurationen, einschließlich Authority- oder Metadaten-URLs der Anwendungen sowie Callback- und Abmelde-URLs der Anbieter.
2. Jede Umgebung verfügt über eine standardmäßige Login-Authentifizierungsmethode namens login. Passen Sie deren Branding und Anmeldeoberfläche an das gewünschte Erscheinungsbild und deren Anmeldeoptionen an die importierten Benutzer an.
3. Erstellen Sie die Authentifizierungsmethoden, die Benutzer mit ihren externen Identitätsanbietern verbinden, einschließlich Okta, falls es Teil des Übergangs bleibt.
4. Konfigurieren Sie die Anwendung, ihre zulässigen Weiterleitungs-URLs, ihr Abmeldeverhalten und alle APIs, die ihre Zugriffstoken akzeptieren.

FoxIDs Cloud bietet den Versand von E-Mails und SMS für Passworteinrichtung, passwortlose Anmeldung und Multi-Faktor-Authentifizierung (MFA), abhängig vom gewählten FoxIDs Cloud Tarif.

Konfigurieren Sie die erforderlichen MFA-Einstellungen und die Registrierung der Benutzer. Die hier beschriebenen CSV-Importe übertragen Benutzerdaten, keine Okta Verify Registrierungen, FastPass Geräteregistrierungen, Passkeys oder sonstigen MFA-Registrierungen. Benutzer, die sich lokal in FoxIDs authentifizieren, registrieren die konfigurierten Authentifizierungsfaktoren. Benutzer, die sich weiterhin über Okta authentifizieren, können ihre dortigen Registrierungen behalten.

Die Anwendungskonfiguration ist ein eigener Arbeitsbereich neben dem Benutzerimport. Prüfen Sie Aussteller, Zielgruppe, Scopes, Claims und Tokenvalidierung sowie Abhängigkeiten von Okta SDK oder Sign-In Widget, Inline Hooks, Gruppenregeln und Anwendungszuweisungen. Erstellen Sie das von der Anwendung benötigte Verhalten neu. Der allgemeine Migrationsleitfaden behandelt die umfassendere Bestandsaufnahme der Anwendungen und die Einführungsschritte.

Eine definierte Gruppe von Okta Benutzern exportieren

Verwenden Sie die Okta Users API, um Benutzerdaten als JSON zur Konvertierung abzurufen. Wählen Sie die Quellorganisation und die zu migrierenden Benutzer oder Gruppen. Folgen Sie der rel="next"-URL im Antwortheader Link, bis alle Seiten gelesen wurden. Die normale Listenoperation lässt DEPROVISIONED-Benutzer aus; eine Filter- oder Suchabfrage kann sie einschließen. Suchergebnisse sind verzögert konsistent, daher können aktuelle Änderungen erst später erscheinen.

Bewahren Sie Quellorganisation und Benutzer-id, Lebenszyklus-status, erforderliche profile-Attribute und credentials.provider-Informationen auf. Halten Sie von Okta verwaltete, verzeichnisgebundene und föderierte Benutzer unterscheidbar. Identitätsanbieterkonfiguration und Routingregeln helfen zu erkennen, wo Benutzer sich tatsächlich authentifizieren.

Für einen berichtsbasierten Export bietet der Bericht User Accounts die Option CSV Export. Seine Spalten müssen weiterhin in das Format des FoxIDs Seed Tools konvertiert werden. Die API ist nützlich, wenn der Import auch benutzerdefinierte Attribute oder Anbieterinformationen benötigt, die im Bericht fehlen.

Exportieren Sie Gruppenmitgliedschaften und Anwendungszugriffe separat, wenn sie Berechtigungen bestimmen. Oktas Bericht Group Membership und Bericht User App Access beschreiben diese Beziehungen; sie sind nicht alle im profile-Objekt des Benutzers enthalten.

Verfügbarkeit von Passwörtern

Okta bietet Passwort-Hash-Exporte ausschließlich für die Migration zu Auth0 und unter bestimmten Voraussetzungen an.

FoxIDs kann unterstützte Passwort-Hashes importieren, wenn sie verfügbar sind.

Benutzerdaten zuordnen und Anwendungskonten beibehalten

FoxIDs erstellt für importierte lokale Benutzer eine eigene dauerhafte Benutzer-ID. Der Import der Okta Benutzer-id als benutzerdefinierter Claim macht sie nicht zur FoxIDs Benutzer-ID und bewahrt nicht automatisch das Subject der Anwendung. Erfassen Sie das tatsächlich von jeder Anwendung verwendete OpenID Connect sub oder SAML NameID zusammen mit Quellorganisation und Benutzer-ID.

Verwendet die Anwendung die Okta Benutzer-ID als sub, importieren Sie diese ID als benutzerdefinierten Claim, etwa legacy_okta_user_id. Konfigurieren Sie auf der Login-Authentifizierungsmethode eine Map-Claim-Transformation mit der Aktion Replace claim, dem Eingabe-Claim legacy_okta_user_id und dem Ausgabe-Claim sub. Die Anwendung erhält dann diesen Wert als sub, während die dauerhafte FoxIDs ID des Benutzers unverändert bleibt. Verwendet die Anwendung einen anderen Subject-Wert, bewahren Sie stattdessen diesen und ordnen ihn zu.

Anwendungen, die Konten anhand von Aussteller und Subject identifizieren, müssen den neuen FoxIDs Aussteller ebenfalls bestehenden Konten zuordnen. Konfigurieren Sie für SAML Anwendungen das benötigte NameID und Format auf der SAML Anwendungsregistrierung. Eine Testanmeldung zeigt die tatsächlich von der Anwendung empfangene Identität.

Pflegen Sie eine Zuordnung zwischen Quellidentität, neuer FoxIDs Identität und bestehendem Anwendungskonto. Die während des Übergangs verwendeten Identitäten sollten auf denselben Kunden- oder Mitarbeiterdatensatz verweisen. Berücksichtigen Sie bei sozialen Anmeldungen und Unternehmensanmeldungen die direkt vom Anbieter empfangene Identität; sie kann von der Okta Benutzer-ID abweichen.

Verwenden Sie für den Import lokaler Benutzer folgende Zuordnung:

Oktas Lebenszykluszustände sind detaillierter als das Deaktivierungsflag von FoxIDs. Die Beispiele aktivieren aus ACTIVE-Konten ausgewählte Benutzer und lassen gesperrte Konten deaktiviert. Zustände wie STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED und LOCKED_OUT benötigen eine ausdrückliche Zuordnung zum gewünschten Aktivierungs-, Passworteinrichtungs- oder Zugriffsverhalten.

Soziale Anmeldungen und Unternehmensanmeldungen migrieren

Erstellen Sie für jeden bisher über Okta verbundenen sozialen oder Unternehmensidentitätsanbieter eine FoxIDs Authentifizierungsmethode mit direktem Vertrauen zu diesem Anbieter. Die Benutzer behalten ihre Konten und Anmeldedaten beim Anbieter.

1. Ermitteln Sie den Anbieter hinter jeder Verbindung. Verwenden Sie die passende Integrationsanleitung für den Anbieter, etwa Google oder Microsoft Entra ID, und wählen Sie die unterstützte Authentifizierungsmethode für OpenID Connect, SAML 2.0 oder WS-Federation.
2. Registrieren oder konfigurieren Sie FoxIDs beim Anbieter. Tauschen Sie Clienteinstellungen oder Föderationsmetadaten aus und konfigurieren Sie die in der Integrationsanleitung angegebenen Callback- und Abmelde-URLs. Behalten Sie die Okta Verbindung während des Übergangs bei.
3. Erlauben Sie die neue Authentifizierungsmethode für die FoxIDs Anwendung. Konfigurieren Sie Home Realm Discovery, damit Benutzer ihren Anbieter auswählen oder über die konfigurierten Regeln dorthin geleitet werden können.
4. Ordnen Sie die Anbieteridentität dem bestehenden Anwendungskonto zu. Wenn Sie benutzerspezifische Claims oder Zugriffszuweisungen in FoxIDs speichern müssen, konfigurieren und provisionieren Sie externe Benutzer.
5. Erstellen Sie die zuvor von Okta durchgesetzten Zugriffsbeschränkungen neu, einschließlich Anwendungszuweisungen, gesperrter Benutzer und erforderlicher MFA.

Der erwartete Ablauf ist Anwendung → FoxIDs → externer Identitätsanbieter → FoxIDs → Anwendung. FoxIDs stellt die Token der Anwendung aus, nachdem der Anbieter den Benutzer authentifiziert hat.

Sie können jede Verbindung ausprobieren, indem Sie die Anmeldung in der Anwendung starten, den Anbieter auswählen und dessen Anmeldeablauf abschließen. So lassen sich MFA, Anwendungskonto und Berechtigungen sowie das Abmeldeverhalten beobachten.

Benutzer aus Active Directory migrieren

Wenn Okta die Passwortauthentifizierung an Active Directory delegiert und AD die Quelle bleibt, kann FoxIDs über den Directory Connector für Active Directory eine direkte Verbindung herstellen. Konfigurieren Sie den Connector und die Login-Authentifizierungsmethode gemäß dieser Anleitung. FoxIDs synchronisiert Benutzer aus AD und validiert Passwörter gegen AD, sodass diese Benutzer keinen CSV-Passwortimport benötigen.

Standardmäßig speichert FoxIDs nach erfolgreicher Directory Connector Validierung eine lokale Passwortkopie. Dies ermöglicht einen späteren Wechsel zur lokalen FoxIDs Authentifizierung durch Deaktivierung des Connectors. Benutzer, deren Passwörter nicht erfasst wurden, können die Passworteinrichtung verwenden. Konfigurationsmöglichkeiten finden Sie unter Passwortverhalten des Directory Connectors.

Ein aus AD stammender Benutzer in Okta authentifiziert sich nicht zwangsläufig weiterhin gegen AD: Okta kann die Passwortauthentifizierung von AD zu Okta migrieren. Die direkte Connector-Anbindung gilt, wenn AD das vom Benutzer verwendete Passwort weiterhin speichert und validiert.

Passwortlose Benutzer migrieren

Importieren Sie Benutzer als interne FoxIDs Benutzer ohne Passwort und konfigurieren Sie passwortlose Anmeldung mit einem E-Mail- oder SMS-Code. Der Benutzer gibt den Code auf der bereits geöffneten Anmeldeseite ein.

Für Benutzer von Okta FastPass oder Passkeys bedeutet dies einen Wechsel der Authentifizierungsmethode. E-Mail- und SMS-Codes bieten nicht die gleiche Phishing-Resistenz wie FastPass.

1. Aktivieren Sie E-Mail oder Telefon als Anmeldekennung auf der Authentifizierungsmethode FoxIDs Login und je nach Bedarf Passwordless with email (one-time password) oder Passwordless with SMS (one-time password).
2. Wählen Sie für eine auf passwortlose Benutzer ausgerichtete Anmeldemethode Disable password authentication und deaktivieren Sie Passworteinrichtung/-zurücksetzung per E-Mail und SMS.
3. Importieren Sie die Benutzer ohne Password und ohne sämtliche Passwort-Hash-Felder. Lassen Sie SetPasswordEmail, SetPasswordSms und ChangePassword auf false. Bewahren Sie den zugeordneten Verifizierungszustand, Deaktivierungszustand und erforderliche Claims.

Diese CSV-Datei für das Seed Tool importiert beispielsweise einen fiktiven Benutzer mit passwortloser E-Mail-Anmeldung, dessen vorheriger E-Mail-Verifizierungszustand unbekannt ist:

Email;EmailVerified;SetPasswordEmail;SetPasswordSms;ChangePassword;DisableAccount;Claims
alice@example.com;false;false;false;false;false;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"

Ersetzen Sie für SMS-Benutzer Email und EmailVerified durch Phone und PhoneVerified und verwenden Sie die ausgewählte Telefonnummer und ihren bekannten Verifizierungszustand. Es gilt dasselbe Uploadverfahren.

Sie können den Ablauf mit einem importierten Testbenutzer ausprobieren, indem Sie dessen E-Mail-Adresse oder Telefonnummer und den erhaltenen Code eingeben. Ein gültiger Code lässt einen aktivierten Benutzer nach gegebenenfalls erforderlicher MFA zur Anwendung gelangen. Nach erfolgreicher passwortloser Anmeldung bleibt der Benutzer ohne Passwort.

Benutzer zur Passworteinrichtung importieren

Aktivieren Sie E-Mail-Anmeldung, Passwortauthentifizierung und Passworteinrichtung per E-Mail auf der Authentifizierungsmethode FoxIDs Login. Importierte Benutzer wählen bei ihrer ersten Anmeldung ein Passwort.

Der Benutzerimport bereitet die Konten vor. Die Passworteinrichtung erfolgt beim Start einer Anmeldung durch den jeweiligen Benutzer, nicht während des Imports.

Konvertieren Sie die geprüften Datensätze in eine UTF-8-Datei für das FoxIDs Seed Tool. Spaltenüberschriften unterscheiden Groß- und Kleinschreibung; das Trennzeichen ist ein Semikolon. Dieses Beispiel enthält fiktive Benutzer mit unbekanntem vorherigem E-Mail-Verifizierungszustand; das zweite Konto bleibt deaktiviert:

Email;EmailVerified;SetPasswordEmail;DisableAccount;RequireMultiFactor;Claims
alice@example.com;false;true;false;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"
suspended@example.com;false;true;true;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO002""]}]"

SetPasswordEmail=true wählt die Passworteinrichtung mit E-Mail-Bestätigung. Lassen Sie Password und alle Passwort-Hash-Spalten weg. RequireMultiFactor=true ist die gewählte Richtlinie des Beispiels und erfordert die Konfiguration der entsprechenden MFA-Methoden.

Geben Sie den Beispiel-Claim legacy_okta_user_id nur über die konfigurierte Claim-Verarbeitung an Anwendungen weiter, die ihn benötigen.

Benutzer hochladen und Ergebnis prüfen

Verwenden Sie dieses Uploadverfahren für passwortlose Benutzer und Benutzer, die bei der ersten Anmeldung ein Passwort wählen sollen, mit den zur gewählten Methode passenden Feldern.

Das Seed Tool trennt Felder an Semikolons; Felder in Anführungszeichen können keine eingebetteten Semikolons oder Zeilenumbrüche enthalten. Verwenden Sie die Benutzeroperationen der Control API, wenn Ihre Werte eine umfangreichere Importdarstellung benötigen.

1. Laden Sie das Seed Tool herunter und konfigurieren Sie es für die gewünschte Umgebung. Setzen Sie SeedSettings.UsersSvcPath auf die konvertierte CSV-Datei.
2. Starten Sie das Seed Tool und wählen Sie U, um die Benutzer gesammelt hochzuladen.
3. Erfassen Sie die neuen Benutzer-IDs in Ihrer Migrationszuordnung.

Sie können den Upload mit einer CSV-Datei mit wenigen Benutzern in einer Testumgebung ausprobieren. Das Seed Tool meldet die Anzahl erfolgreicher und fehlgeschlagener Vorgänge. Die importierten Benutzer lassen sich in FoxIDs Control auf Kennungen, Deaktivierungszustand, Claims und Passworteinrichtungsflags prüfen.

Das Seed Tool verwendet Massenprovisionierung, die bestehende Benutzer ersetzen kann, statt sie zusammenzuführen. Ein wiederholter Upload kann Anmeldedaten und Zustand entfernen und neue Benutzer-IDs erzeugen. Gleichen Sie bei einem teilweise abgeschlossenen Import das Ergebnis vor einem erneuten Versuch ab; verwenden Sie für spätere Änderungen gezielte Benutzeraktualisierungen.

Passworteinrichtung bei der ersten Anmeldung

Für einen aktivierten importierten Benutzer mit SetPasswordEmail=true ist folgender Ablauf zu erwarten:

1. Der Benutzer öffnet die Anwendung und startet die Anmeldung über FoxIDs Login.
2. FoxIDs identifiziert den Benutzer anhand der E-Mail-Adresse und sendet einen Bestätigungscode.
3. Der Benutzer übermittelt den Code und ein neues Passwort, das der FoxIDs Passwortrichtlinie entspricht.
4. FoxIDs verifiziert die E-Mail-Adresse, speichert das Passwort und setzt die Passworteinrichtungsflags zurück. Die Anmeldung durchläuft gegebenenfalls erforderliche MFA-Schritte, bevor sie zur Anwendung zurückkehrt.

Der Benutzerimport sendet keine Einrichtungs-E-Mail. Spätere Passwortanmeldungen verwenden das neue FoxIDs Passwort. Kann ein Benutzer den Code nicht empfangen, benötigt der Wiederherstellungsprozess eine andere Möglichkeit zur Identitätsverifizierung.

Sie können den Ablauf mit einem Testbenutzer anhand der obigen Anmeldeschritte erkunden. Diese Szenarien zeigen die erwarteten Ergebnisse:

Okta während des Übergangs beibehalten

FoxIDs kann Okta während des Wechsels der Anwendungen zu FoxIDs als externem Identitätsanbieter vertrauen. Benutzer authentifizieren sich bei Okta, und FoxIDs stellt Token für die Anwendung aus. Dadurch verbleiben Okta Passwörter und Authentifikatoren bei Okta; sie werden nicht nach FoxIDs kopiert.

Für eine OpenID Connect Verbindung:

1. Erstellen Sie in Okta eine OIDC Webanwendungsintegration für FoxIDs mit Authorization Code Flow. Weisen Sie die Benutzer oder Gruppen zu, die sich über diese Integration anmelden sollen, und konfigurieren Sie ihre Anmelderichtlinie.
2. Erstellen Sie in FoxIDs eine OpenID Connect Authentifizierungsmethode. Setzen Sie Authority auf den gewählten Okta Aussteller und konfigurieren Sie die Okta Client-ID unter Optional custom SP client ID, das Client-Secret und die passende Clientauthentifizierungsmethode für den Tokenendpunkt.
3. Fordern Sie nach Bedarf die Scopes profile und email an; FoxIDs schließt openid ein. Wählen Sie unter Show advanced die Option Read claims from the UserInfo Endpoint instead of the access token or ID token, um die Claims des Benutzers über UserInfo abzurufen.
4. Registrieren Sie die von FoxIDs angezeigte Redirect URL als Weiterleitungs-URI für die Anmeldung in Okta und konfigurieren Sie bei Verwendung der Abmeldung die entsprechende Abmelde-Weiterleitungs-URI.
5. Erlauben Sie die Authentifizierungsmethode für die FoxIDs Anwendung und konfigurieren Sie Home Realm Discovery für Benutzer, die weiterhin Okta verwenden.

Oktas Organisationsautorisierungsserver unterstützt OpenID Connect Anmeldung mit einem Aussteller wie https://example.okta.com. Ein benutzerdefinierter Autorisierungsserver verwendet einen Aussteller wie https://example.okta.com/oauth2/default. Verwenden Sie den für die Integration gewählten Aussteller und die Claim-Konfiguration.

Eine SAML Authentifizierungsmethode ist eine weitere Möglichkeit: Erstellen Sie in Okta eine SAML Anwendung für FoxIDs und tauschen Sie Metadaten und Einstellungen von Dienst- und Identitätsanbieter aus.

Eine Testanmeldung über die Anwendung zeigt Oktas Authentifizierungsrichtlinie, Claims, Kontozuordnung und Abmeldeverhalten für die neue Verbindung. Wenn Benutzer zur lokalen FoxIDs Anmeldung oder zu direkt verbundenen Anbietern wechseln, leiten Sie sie zu diesen Authentifizierungsmethoden. Eine abgestimmte Kontozuordnung über alle Methoden ermöglicht der Anwendung die weitere Nutzung derselben Kontodatensätze.

Einführen und Rückkehrmöglichkeit beibehalten

Die Migration kann je Anwendung oder Benutzergruppe eingeführt werden. Benutzer können über ihre gewohnte Anwendungs-URL mit dem konfigurierten Anmeldeablauf fortfahren: Passworteinrichtung, Einmalcode, Verzeichnispasswort oder externer Identitätsanbieter.

Gleichen Sie seit dem Export erstellte, geänderte, gesperrte oder gelöschte Benutzer ab, einschließlich Änderungen an Gruppen und Anwendungszuweisungen. Ein kurzer Änderungsstopp oder kontrollierter Abgleichprozess kann Quelle und Ziel während der Umstellung konsistent halten. Spätere Aktualisierungen sollten bereits in FoxIDs eingerichtete Anmeldedaten und Zustände bewahren.

Überwachen Sie E-Mail- und SMS-Zustellung, Einrichtungsfehler, Anmeldefehler und Kontozuordnungsprobleme. Ein Rollback setzt voraus, dass die bisherige Okta Konfiguration verfügbar bleibt. Sie können ihre Wiederherstellung für eine Testanwendung ausprobieren und die Rückkehr zum Okta Anmeldeablauf beobachten.

Ein lokal in FoxIDs gesetztes Passwort wird nicht zurück zu Okta synchronisiert. Ein Rollback verwendet daher die weiterhin bei Okta oder dessen verbundenem Anbieter gespeicherten Anmeldedaten. Nur in FoxIDs erstellte Benutzer benötigen bei einem nötigen Rollback einen Zugangsweg. Sobald die erforderlichen Benutzer und Anwendungen ihre Zielauthentifizierungsmethoden verwenden, kann die Okta Integration außer Betrieb genommen werden.

Zugehörige Dokumentation

• Migrationsübersicht
• Viele Benutzer hochladen
• Benutzeroperationen der Control API
• Anmeldung und Home Realm Discovery
• Directory Connector for Active Directory
• OpenID Connect Authentifizierungsmethode