Migrera från Okta till FoxIDs

Flytta inloggningar från Okta till FoxIDs med den migreringsmetod som passar var varje användargrupp autentiseras. Importera lokala användare och låt dem välja ett nytt lösenord eller aktivera lösenordsfri inloggning med engångskoder. För sociala inloggningar och företagsinloggningar konfigurerar du autentiseringsmetoder i FoxIDs som litar på de externa identitetsleverantörerna. Okta kan också fortsätta vara identitetsleverantör medan applikationerna flyttas till FoxIDs.

Den här tekniska guiden omfattar användare i Okta Universal Directory, applikationskonfiguration och kontokoppling för Okta Identity Engine och Classic Engine.

För import av lokala användare konverterar du den granskade exporten från Okta till en CSV-fil och använder FoxIDs Seed Tool för att massinläsa användarna i FoxIDs. CSV-exemplen nedan visar fälten för lösenordsinställning och lösenordsfri inloggning.

Välj en metod för varje grupp:

Förbered målmiljön och applikationen

En särskild testmiljö låter dig prova migreringen med en liten användargrupp innan övergången till produktion. Konfigurationen omfattar:

1. Om du vill ha en anpassad domän, konfigurera och verifiera den för tenanten innan du konfigurerar applikationer och externa identitetsleverantörer. Använd de resulterande FoxIDs URL:erna under hela migreringen. Om domänen ändras senare måste externa konfigurationer uppdateras, bland annat applikationernas authority- eller metadata-URL:er och leverantörernas callback- och utloggnings-URL:er.
2. Varje miljö har en förvald Login autentiseringsmetod med namnet login. Anpassa dess varumärkesprofilering och inloggningsgränssnitt till önskat utseende och justera inloggningsalternativen för de importerade användarna.
3. Skapa de autentiseringsmetoder som ansluter användarna till deras externa identitetsleverantörer, inklusive Okta om det ingår i övergången.
4. Konfigurera applikationen, dess tillåtna omdirigerings-URL:er och utloggningsbeteende samt de API:er som accepterar dess åtkomsttoken.

FoxIDs Cloud tillhandahåller leverans av e-post och SMS för skapande av lösenord, lösenordsfri inloggning och multifaktorautentisering (MFA), beroende på vald FoxIDs Cloud plan.

Konfigurera nödvändiga MFA-inställningar och hur användarna ska registrera sig. CSV-importerna som beskrivs här överför användardata, inte registreringar för Okta Verify, enhetsregistreringar för FastPass, passkeys eller andra MFA-registreringar. Användare som autentiseras lokalt i FoxIDs registrerar de konfigurerade autentiseringsfaktorerna. Användare som fortsätter autentiseras via Okta kan behålla sina registreringar där.

Applikationskonfiguration är ett separat arbete från användarimport. Granska utfärdare, målgrupp, scopes, claims och tokenvalidering samt beroenden till Okta SDK eller Sign-In Widget, inline hooks, gruppregler och applikationstilldelningar. Återskapa det beteende som applikationen kräver. Den allmänna migreringsguiden beskriver den övergripande applikationsinventeringen och driftsättningsstegen.

Exportera en avgränsad grupp Okta användare

Använd Okta Users API för att hämta användardata som JSON för konvertering. Välj källorganisationen och de användare eller grupper som ska migreras. Följ URL:en för rel="next" i svarshuvudet Link tills alla sidor har lästs. Den vanliga listoperationen utelämnar användare med DEPROVISIONED; en filter- eller sökfråga kan inkludera dem. Sökresultat är så småningom konsistenta, så det kan ta tid innan nya ändringar visas.

Bevara källorganisationen och användarens id, livscykelns status, nödvändiga profile-attribut och information om credentials.provider. Håll användare som hanteras av Okta, kataloganslutna användare och federerade användare åtskilda. Konfigurationen för identitetsleverantörer och routningsregler hjälper till att identifiera var användarna faktiskt autentiseras.

För en rapportbaserad export erbjuder rapporten User Accounts alternativet CSV Export. Dess kolumner behöver fortfarande konverteras till FoxIDs Seed Tools format. API:et är användbart när importen också behöver anpassade attribut eller leverantörsinformation som saknas i rapporten.

Exportera gruppmedlemskap och applikationsåtkomst separat när de avgör behörigheter. Oktas rapport Group Membership och rapport User App Access beskriver dessa relationer; de finns inte alla i användarens profile-objekt.

Tillgång till lösenord

Okta erbjuder endast export av lösenordshashar för migrering till Auth0, under vissa förutsättningar.

FoxIDs kan importera lösenordshashar som stöds när de är tillgängliga.

Mappa användaruppgifter och bevara applikationskonton

FoxIDs skapar ett eget beständigt användar-ID för importerade lokala användare. Import av användarens Okta id som en anpassad claim gör det inte till användarens FoxIDs ID och bevarar inte automatiskt applikationens subject. Registrera det faktiska OpenID Connect sub eller SAML NameID som används av varje applikation tillsammans med källorganisationen och användar-ID:t.

Om applikationen använder användarens Okta ID som sitt sub importerar du detta ID som en anpassad claim, exempelvis legacy_okta_user_id. På autentiseringsmetoden Login konfigurerar du en Map claim-transformering med åtgärden Replace claim, inkommande claim legacy_okta_user_id och utgående claim sub. Applikationen får då detta värde som sub, medan användarens beständiga FoxIDs ID förblir oförändrat. Om applikationen använder ett annat subject-värde bevarar och mappar du det värdet i stället.

Applikationer som identifierar konton med både utfärdare och subject behöver också koppla den nya FoxIDs utfärdaren till befintliga konton. För SAML applikationer konfigurerar du nödvändigt NameID och format på SAML applikationsregistreringen. En testinloggning visar den faktiska identitet som applikationen får.

Underhåll en mappning mellan källidentiteten, den nya FoxIDs identiteten och det befintliga applikationskontot. Identiteterna som används under övergången ska motsvara samma kund- eller medarbetarpost. För sociala inloggningar och företagsinloggningar inkluderar du identiteten som erhålls direkt från leverantören; den kan skilja sig från användarens Okta ID.

Använd följande mappning vid import av lokala användare:

Oktas livscykelstatusar är mer detaljerade än FoxIDs inaktiveringsflagga. Exemplen aktiverar användare som valts från konton med ACTIVE och låter avstängda konton vara inaktiverade. Statusar som STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED och LOCKED_OUT behöver en uttrycklig mappning till avsett beteende för aktivering, lösenordsinställning eller åtkomst.

Migrera sociala inloggningar och företagsinloggningar

Skapa en autentiseringsmetod i FoxIDs för varje social identitetsleverantör eller företagsleverantör som för närvarande är ansluten via Okta, med direkt tillit till leverantören. Användarna behåller sina konton och autentiseringsuppgifter hos leverantören.

1. Identifiera leverantören bakom varje anslutning. Använd relevant integrationsguide för leverantören, exempelvis Google eller Microsoft Entra ID, och välj en autentiseringsmetod som stöds för OpenID Connect, SAML 2.0 eller WS-Federation.
2. Registrera eller konfigurera FoxIDs hos leverantören. Utbyt klientinställningar eller federationsmetadata och konfigurera de callback- och utloggnings-URL:er som integrationsguiden anger. Behåll anslutningen till Okta under övergången.
3. Tillåt den nya autentiseringsmetoden i FoxIDs applikationen. Konfigurera Home Realm Discovery så att användarna kan välja leverantör eller dirigeras dit enligt konfigurerade regler.
4. Mappa leverantörsidentiteten till det befintliga applikationskontot. Om du behöver lagra användarspecifika claims eller åtkomsttilldelningar i FoxIDs konfigurerar och etablerar du externa användare.
5. Återskapa åtkomstbegränsningar som tidigare upprätthölls av Okta, inklusive applikationstilldelningar, avstängda användare och obligatorisk MFA.

Det förväntade flödet är applikation → FoxIDs → extern identitetsleverantör → FoxIDs → applikation. FoxIDs utfärdar applikationens token efter att leverantören har autentiserat användaren.

Du kan prova varje anslutning genom att starta inloggning från applikationen, välja leverantör och genomföra dess inloggningsflöde. Det visar MFA, applikationskonto och behörigheter samt utloggningsbeteende.

Migrera användare från Active Directory

Om Okta delegerar lösenordsautentisering till Active Directory och AD förblir källan kan FoxIDs ansluta direkt via Directory Connector för Active Directory. Konfigurera connectorn och autentiseringsmetoden Login enligt guiden. FoxIDs synkroniserar användare från AD och validerar lösenord mot AD, så dessa användare behöver ingen lösenordsimport via CSV.

Som standard sparar FoxIDs en lokal lösenordskopia efter lyckad validering med Directory Connector. Det möjliggör en senare övergång till lokal autentisering i FoxIDs genom att inaktivera connectorn. Användare vars lösenord inte har sparats kan använda lösenordsinställning. Se Directory Connectors lösenordshantering för konfigurationsalternativ.

En användare i Okta med AD som källa autentiseras inte nödvändigtvis fortfarande mot AD: Okta kan migrera lösenordsautentisering från AD till Okta. Direktanslutning med connectorn gäller när AD fortfarande lagrar och validerar lösenordet som användaren använder.

Migrera lösenordsfria användare

Importera användare som interna FoxIDs användare utan lösenord och konfigurera lösenordsfri inloggning med en kod via e-post eller SMS. Användaren anger koden på den inloggningssida som redan är öppen.

Detta innebär ett byte av autentiseringsmetod för användare av Okta FastPass eller passkeys. E-post- och SMS-koder ger inte samma motståndskraft mot nätfiske som FastPass.

1. Aktivera e-post eller telefon som inloggningsidentifierare på FoxIDs Login autentiseringsmetoden och aktivera Passwordless with email (one-time password) eller Passwordless with SMS (one-time password) efter behov.
2. För en inloggningsmetod avsedd för lösenordsfria användare väljer du Disable password authentication och inaktiverar lösenordsinställning/återställning via e-post och SMS.
3. Importera användarna utan Password och alla lösenordshashfält. Låt SetPasswordEmail, SetPasswordSms och ChangePassword vara false. Bevara mappad verifieringsstatus, inaktiveringsstatus och nödvändiga claims.

Denna CSV-fil för Seed Tool importerar exempelvis en fiktiv användare med lösenordsfri e-postinloggning vars tidigare e-postverifieringsstatus är okänd:

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

För SMS-användare ersätter du Email och EmailVerified med Phone och PhoneVerified, med det valda telefonnumret och dess kända verifieringsstatus. Samma uppladdningsförfarande gäller.

Du kan prova flödet med en importerad testanvändare genom att ange användarens e-postadress eller telefonnummer och den mottagna koden. En giltig kod låter en aktiverad användare fortsätta genom eventuell obligatorisk MFA till applikationen. Användaren förblir utan lösenord efter lyckad lösenordsfri inloggning.

Importera användare för lösenordsinställning

Aktivera e-postinloggning, lösenordsautentisering och lösenordsinställning via e-post på autentiseringsmetoden FoxIDs Login. Importerade användare väljer ett lösenord under sin första inloggning.

Användarimporten förbereder kontona. Lösenordet anges när varje användare påbörjar en inloggning, inte under importen.

Konvertera de granskade posterna till en UTF-8-fil för FoxIDs Seed Tool. Kolumnrubrikerna är skiftlägeskänsliga och avgränsaren är ett semikolon. Exemplet innehåller fiktiva användare vars tidigare e-postverifieringsstatus är okänd; det andra kontot förblir inaktiverat:

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 väljer lösenordsinställning med e-postbekräftelse. Utelämna Password och alla kolumner för lösenordshashar. RequireMultiFactor=true är exemplets valda policy och kräver att motsvarande MFA-metoder konfigureras.

Lämna endast ut exemplets claim legacy_okta_user_id till applikationer som behöver den genom deras konfigurerade claim-hantering.

Ladda upp användare och granska resultatet

Använd detta uppladdningsförfarande för lösenordsfria användare och användare som ska välja ett lösenord vid första inloggningen, med fälten för den valda metoden.

Seed Tool delar upp fält vid semikolon; citerade fält kan inte innehålla semikolon eller radbrytningar. Använd Control API:s användaroperationer om värdena kräver en mer uttrycksfull importrepresentation.

1. Ladda ned och konfigurera Seed Tool för den avsedda miljön. Ange sökvägen till den konverterade CSV-filen i SeedSettings.UsersSvcPath.
2. Kör Seed Tool och välj U för att massuppladda användarna.
3. Registrera de nya användar-ID:na i din migreringsmappning.

Du kan prova uppladdningen med en CSV-fil med några användare i en testmiljö. Seed Tool rapporterar antalet lyckade och misslyckade operationer. De importerade användarna kan granskas i FoxIDs Control för att se identifierare, inaktiveringsstatus, claims och flaggor för lösenordsinställning.

Seed Tool använder massetablering som kan ersätta befintliga användare i stället för att sammanfoga dem. En upprepad uppladdning kan ta bort autentiseringsuppgifter och tillstånd och skapa nya användar-ID:n. Vid en delvis genomförd import stämmer du av resultatet innan du försöker igen; använd riktade användaruppdateringar för senare ändringar.

Lösenordsinställning vid första inloggningen

För en aktiverad importerad användare med SetPasswordEmail=true är det förväntade flödet:

1. Användaren öppnar applikationen och påbörjar inloggning via FoxIDs Login.
2. FoxIDs identifierar användaren genom e-postadressen och skickar en bekräftelsekod.
3. Användaren skickar in koden och ett nytt lösenord som uppfyller FoxIDs lösenordspolicy.
4. FoxIDs verifierar e-postadressen, sparar lösenordet och nollställer flaggorna för lösenordsinställning. Inloggningen fortsätter genom eventuella obligatoriska MFA-steg innan användaren återgår till applikationen.

Import av en användare skickar inte e-postmeddelandet för lösenordsinställning. Efterföljande lösenordsinloggningar använder det nya lösenordet i FoxIDs. Om användaren inte kan ta emot koden behöver återställningsprocessen ett annat sätt att verifiera identiteten.

Du kan utforska flödet med en testanvändare genom att följa inloggningsstegen ovan. Dessa scenarier visar de förväntade resultaten:

Behåll Okta under övergången

FoxIDs kan lita på Okta som extern identitetsleverantör medan applikationer flyttas till FoxIDs. Användarna autentiseras hos Okta och FoxIDs utfärdar token till applikationen. Därmed behålls Oktas lösenord och autentiseringsmedel hos Okta; de kopieras inte till FoxIDs.

För en OpenID Connect anslutning:

1. Skapa en OIDC webbapplikationsintegration i Okta för FoxIDs med Authorization Code Flow. Tilldela användarna eller grupperna som ska logga in genom integrationen och konfigurera dess inloggningspolicy.
2. Skapa en OpenID Connect autentiseringsmetod i FoxIDs. Ange vald Okta utfärdare i Authority och konfigurera Oktas klient-ID under Optional custom SP client ID, dess klienthemlighet och motsvarande klientautentiseringsmetod för token-endpointen.
3. Begär scopes profile och email efter behov; FoxIDs inkluderar openid. Välj Read claims from the UserInfo Endpoint instead of the access token or ID token under Show advanced för att hämta användarens claims genom UserInfo.
4. Registrera den Redirect URL som visas av FoxIDs som omdirigerings-URI för inloggning i Okta och konfigurera motsvarande omdirigerings-URI för utloggning när utloggning används.
5. Tillåt autentiseringsmetoden på applikationen i FoxIDs och konfigurera Home Realm Discovery för användarna som fortsätter via Okta.

Oktas organisationsauktoriseringsserver stöder OpenID Connect inloggning med en utfärdare som https://example.okta.com. En anpassad auktoriseringsserver använder en utfärdare som https://example.okta.com/oauth2/default. Använd den utfärdare och claim-konfiguration som valts för integrationen.

En SAML autentiseringsmetod är ett annat alternativ: skapa en SAML applikation i Okta för FoxIDs och utbyt metadata och inställningar för tjänsteleverantör och identitetsleverantör.

En testinloggning via applikationen visar Oktas autentiseringspolicy, claims, kontomappning och utloggningsbeteende för den nya anslutningen. När användarna går över till lokal inloggning i FoxIDs eller direktanslutna leverantörer dirigerar du dem till dessa autentiseringsmetoder. Genom att hålla applikationens kontomappning samstämmig mellan metoderna kan den fortsätta använda samma kontoposter.

Driftsätt och behåll möjligheten att återgå

Migreringen kan genomföras per applikation eller användargrupp. Användarna kan fortsätta via sin vanliga applikations-URL med det konfigurerade inloggningsflödet: lösenordsinställning, en engångskod, sitt kataloglösenord eller en extern identitetsleverantör.

Stäm av användare som skapats, ändrats, stängts av eller tagits bort sedan exporten, inklusive ändringar i grupper och applikationstilldelningar. Ett kort ändringsstopp eller en kontrollerad avstämningsprocess kan hålla källa och mål samstämmiga under övergången. Senare uppdateringar bör bevara autentiseringsuppgifter och tillstånd som redan etablerats i FoxIDs.

Övervaka leverans av e-post och SMS, misslyckad lösenordsinställning, inloggningsfel och problem med kontomappning. Återgång kräver att den tidigare konfigurationen i Okta fortfarande finns tillgänglig. Du kan prova att återställa konfigurationen för en testapplikation för att se återgången till inloggningsflödet i Okta.

Ett lösenord som anges lokalt i FoxIDs synkroniseras inte tillbaka till Okta. En återgång använder därför de autentiseringsuppgifter som fortfarande finns hos Okta eller dess anslutna leverantör. Användare som bara skapats i FoxIDs behöver en åtkomstväg om en återgång krävs. När de nödvändiga användarna och applikationerna använder sina avsedda autentiseringsmetoder kan integrationen med Okta avvecklas.

Relaterad dokumentation

• Migreringsöversikt
• Ladda upp många användare
• Control API:s användaroperationer
• Inloggning och Home Realm Discovery
• Directory Connector for Active Directory
• OpenID Connect autentiseringsmetod