Migrer fra Okta til FoxIDs

Flyt Okta login til FoxIDs med den migreringsmetode, der passer til, hvor hver brugergruppe autentificeres. Importér lokale brugere, og lad dem vælge en ny adgangskode, eller aktivér login uden adgangskode med engangskoder. Ved login gennem sociale tjenester og virksomheders identitetsudbydere konfigureres FoxIDs autentificeringsmetoder, som har tillid til de eksterne identitetsudbydere. Okta kan også fortsætte som identitetsudbyder, mens applikationerne flyttes til FoxIDs.

Denne tekniske guide dækker brugere i Okta Universal Directory, applikationskonfiguration og kontotilknytning for Okta Identity Engine og Classic Engine.

Ved import af lokale brugere konverteres den gennemgåede Okta eksport til en CSV-fil, hvorefter FoxIDs Seed Tool bruges til at masseindlæse brugerne i FoxIDs. CSV-eksemplerne nedenfor viser felterne til oprettelse af adgangskode og login uden adgangskode.

Vælg en fremgangsmåde for hver gruppe:

Forbered målmiljøet og applikationen

Et dedikeret testmiljø gør det muligt at afprøve migreringen med en lille gruppe brugere før overgangen til produktion. Konfigurationen omfatter:

1. Hvis du ønsker et brugerdefineret domæne, skal det konfigureres og verificeres på tenanten, før applikationer og eksterne identitetsudbydere konfigureres. Brug de resulterende FoxIDs URL'er gennem hele migreringen. Ændres domænet senere, kræver det opdatering af eksterne konfigurationer, herunder applikationernes authority- eller metadata-URL'er og udbydernes callback- og logout-URL'er.
2. Hvert miljø har en standard Login autentificeringsmetode med navnet login. Tilpas dens branding og login-UI til det ønskede udseende, og justér dens loginindstillinger til de importerede brugere.
3. Opret de autentificeringsmetoder, som forbinder brugerne med deres eksterne identitetsudbydere, herunder Okta, hvis det fortsat indgår i overgangen.
4. Konfigurér applikationen, dens tilladte redirect-URL'er og logoutadfærd samt de API'er, der accepterer dens adgangstokens.

FoxIDs Cloud tilbyder levering af e-mail og SMS til oprettelse af adgangskoder, login uden adgangskode og multifaktorgodkendelse (MFA), afhængigt af den valgte FoxIDs Cloud plan.

Konfigurér de nødvendige MFA-indstillinger, og hvordan brugerne tilmelder sig. De beskrevne CSV-importer overfører brugerdata, ikke registreringer til Okta Verify, FastPass-enheder, passkeys eller andre MFA-metoder. Brugere, der autentificeres lokalt i FoxIDs, tilmelder sig de konfigurerede autentificeringsfaktorer. Brugere, der fortsætter med at autentificere sig gennem Okta, kan beholde deres Okta registreringer.

Applikationskonfiguration er et særskilt arbejde ved siden af brugerimport. Gennemgå issuer, audience, scopes, claims og tokenvalidering samt afhængigheder af Okta SDK eller Sign-In Widget, inline hooks, grupperegler og applikationstildelinger. Genskab den adfærd, applikationen kræver. Den generelle migreringsguide dækker den samlede applikationsoversigt og udrulningens trin.

Eksportér en afgrænset gruppe Okta brugere

Brug Okta Users API til at hente brugerdata som JSON til konvertering. Vælg kildeorganisationen og de brugere eller grupper, der migreres. Følg URL'en med rel="next" i svarheaderen Link, indtil alle sider er læst. Den almindelige listeoperation udelader brugere med DEPROVISIONED; en filter- eller søgeforespørgsel kan medtage dem. Søgeresultater opdateres med forsinkelse, så det kan tage tid, før nye ændringer vises.

Bevar kildeorganisationen og brugerens id, livscyklusfeltet status, nødvendige profile-attributter og oplysninger fra credentials.provider. Hold brugere administreret af Okta, brugere fra kataloger og fødererede brugere adskilt. Identitetsudbyderens konfiguration og routingregler hjælper med at fastslå, hvor brugerne faktisk autentificeres.

Til rapportbaseret eksport har User Accounts-rapporten en CSV Export-funktion. Kolonnerne skal stadig konverteres til FoxIDs Seed Tools format. API'et er nyttigt, når importen også kræver brugerdefinerede attributter eller udbyderoplysninger, som ikke findes i rapporten.

Eksportér gruppemedlemskab og applikationsadgang særskilt, når de bestemmer rettighederne. Oktas Group Membership-rapport og User App Access-rapport beskriver disse relationer; de findes ikke alle i brugerens profile-objekt.

Adgang til adgangskoder

Okta tilbyder kun eksport af adgangskodehashes ved migrering til Auth0, under bestemte forudsætninger.

FoxIDs kan importere understøttede adgangskodehashes, når de er tilgængelige.

Tilknyt brugerdata og bevar applikationskonti

FoxIDs opretter sit eget permanente bruger-ID til importerede lokale brugere. Import af Okta brugerens id som en brugerdefineret claim gør det ikke til FoxIDs bruger-ID og bevarer ikke automatisk applikationens subject. Registrér den faktiske OpenID Connect sub eller SAML NameID, som hver applikation bruger, sammen med kildeorganisationen og bruger-ID'et.

Hvis applikationen bruger Okta bruger-ID'et som sub, importeres ID'et som en brugerdefineret claim, eksempelvis legacy_okta_user_id. Konfigurér en Map claim transform på Login autentificeringsmetoden med handlingen Replace claim, inputclaim legacy_okta_user_id og outputclaim sub. Applikationen modtager så værdien som sub, mens brugerens permanente FoxIDs ID er uændret. Hvis applikationen bruger en anden subject-værdi, bevares og mappes denne værdi i stedet.

Applikationer, der identificerer konti med både issuer og subject, skal også knytte den nye FoxIDs issuer til de eksisterende konti. For SAML-applikationer konfigureres det nødvendige NameID og format på SAML-applikationsregistreringen. Et testlogin viser den faktiske identitet, som applikationen modtager.

Vedligehold en mapping mellem kildeidentiteten, den nye FoxIDs identitet og den eksisterende applikationskonto. Identiteterne under overgangen skal pege på samme kunde- eller medarbejderpost. For login via sociale tjenester og virksomheders identitetsudbydere medtages identiteten modtaget direkte fra udbyderen; den kan afvige fra Okta bruger-ID'et.

Brug følgende tilknytning ved import af lokale brugere:

Oktas livscyklustilstande er mere detaljerede end FoxIDs' deaktiveringsflag. Eksemplerne aktiverer brugere udvalgt blandt ACTIVE-konti og holder suspenderede konti deaktiveret. Tilstande som STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED og LOCKED_OUT kræver en eksplicit mapping til den ønskede aktivering, adgangskodeopsætning eller adgangsadfærd.

Migrer login via sociale tjenester og virksomheders identitetsudbydere

Opret en FoxIDs autentificeringsmetode for hver social tjeneste eller virksomhedsidentitetsudbyder, som i dag er tilsluttet gennem Okta, så der etableres tillid direkte til udbyderen. Brugerne beholder deres konti og legitimationsoplysninger hos udbyderen.

1. Identificér udbyderen bag hver forbindelse. Brug den relevante integrationsguide til udbyderen, eksempelvis Google eller Microsoft Entra ID, og vælg den understøttede autentificeringsmetode med OpenID Connect, SAML 2.0 eller WS-Federation.
2. Registrér eller konfigurér FoxIDs hos udbyderen. Udveksl klientindstillinger eller føderationsmetadata, og konfigurér de callback- og logout-URL'er, som integrationsguiden angiver. Bevar Okta forbindelsen under overgangen.
3. Tillad den nye autentificeringsmetode på FoxIDs applikationen. Konfigurér Home Realm Discovery, så brugerne kan vælge deres udbyder eller ledes til den af de konfigurerede regler.
4. Map udbyderidentiteten til den eksisterende applikationskonto. Hvis du skal gemme claims eller adgangstildelinger pr. bruger i FoxIDs, konfigureres og provisioneres eksterne brugere.
5. Genskab de adgangsbegrænsninger, som Okta tidligere håndhævede, herunder applikationstildelinger, suspenderede brugere og påkrævet MFA.

Det forventede flow er applikation → FoxIDs → ekstern identitetsudbyder → FoxIDs → applikation. FoxIDs udsteder applikationens tokens, efter at udbyderen har autentificeret brugeren.

Du kan afprøve hver forbindelse ved at starte login fra applikationen, vælge udbyderen og gennemføre dens loginflow. Det gør det muligt at se MFA, applikationskonto og rettigheder samt logoutadfærd.

Migrer brugere fra Active Directory

Hvis Okta delegerer adgangskodeautentificering til Active Directory, og AD fortsat er kilden, kan FoxIDs forbindes direkte gennem Directory Connector til Active Directory. Konfigurér connectoren og Login autentificeringsmetoden som beskrevet i den guide. FoxIDs synkroniserer brugere fra AD og validerer adgangskoder mod AD, så disse brugere ikke behøver import af adgangskoder via CSV.

Som standard gemmer FoxIDs en lokal adgangskodekopi efter vellykket validering gennem Directory Connector. Det understøtter en senere overgang til lokal FoxIDs autentificering ved at deaktivere connectoren. Brugere, hvis adgangskoder ikke er gemt, kan benytte oprettelse af adgangskode. Se Directory Connectors håndtering af adgangskoder for konfigurationsmuligheder.

En bruger i Okta, som stammer fra AD, autentificeres ikke nødvendigvis stadig mod AD: Okta kan migrere adgangskodeautentificering fra AD til Okta. Den direkte connectorløsning gælder, når AD stadig indeholder og validerer den adgangskode, brugeren anvender.

Migrer brugere uden adgangskode

Importér brugere som interne FoxIDs brugere uden adgangskoder, og konfigurér login uden adgangskode med en e-mail- eller SMS-kode. Brugeren indtaster koden på den loginside, vedkommende allerede har åbnet.

Dette ændrer autentificeringsmetoden for brugere af Okta FastPass eller passkeys. E-mail- og SMS-koder giver ikke samme modstandsdygtighed mod phishing som FastPass.

1. Aktivér e-mail eller telefon som loginidentifikator på FoxIDs Login autentificeringsmetoden, og aktivér Passwordless with email (one-time password) eller Passwordless with SMS (one-time password) efter behov.
2. For en loginmetode dedikeret til brugere uden adgangskode vælges Disable password authentication, og oprettelse/nulstilling af adgangskode via e-mail og SMS deaktiveres.
3. Importér brugerne uden Password og alle felter til adgangskodehash. Hold SetPasswordEmail, SetPasswordSms og ChangePassword false. Bevar den mappede verificeringstilstand, deaktiveringstilstand og nødvendige claims.

Denne Seed Tool CSV importerer eksempelvis en fiktiv bruger med login uden adgangskode via e-mail, hvor den tidligere verificeringstilstand for e-mail er ukendt:

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

For SMS-brugere erstattes Email og EmailVerified med Phone og PhoneVerified med det valgte telefonnummer og dets kendte verificeringstilstand. Den samme uploadprocedure gælder.

Du kan afprøve forløbet med en importeret testbruger ved at indtaste brugerens e-mailadresse eller telefonnummer og den modtagne kode. En gyldig kode lader en aktiveret bruger fortsætte gennem eventuel påkrævet MFA til applikationen. Brugeren har stadig ingen adgangskode efter vellykket login uden adgangskode.

Importér brugere til oprettelse af adgangskode

Aktivér login med e-mail, adgangskodeautentificering og oprettelse af adgangskode via e-mail på FoxIDs Login autentificeringsmetoden. Importerede brugere vælger en adgangskode under deres første login.

Brugerimporten klargør kontiene. Adgangskoden oprettes, når hver bruger starter et login, ikke under importen.

Konvertér de gennemgåede poster til en UTF-8-fil til FoxIDs Seed Tool. Kolonneoverskrifter skelner mellem store og små bogstaver, og separatoren er semikolon. Eksemplet indeholder fiktive brugere, hvis tidligere verificeringstilstand for e-mail er ukendt; den anden konto forbliver deaktiveret:

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ælger oprettelse af adgangskode med e-mailbekræftelse. Udelad Password og alle kolonner til adgangskodehash. RequireMultiFactor=true er den politik, der er valgt i eksemplet, og kræver, at de tilsvarende MFA-metoder er konfigureret.

Udsted kun eksemplets legacy_okta_user_id claim til applikationer, der har brug for den, gennem deres konfigurerede claim-håndtering.

Upload brugere og gennemgå resultatet

Brug denne uploadprocedure til brugere uden adgangskode og brugere, som vælger en adgangskode ved første login, med de felter, der passer til den valgte metode.

Seed Tool opdeler felter ved semikolon; felter i anførselstegn kan ikke indeholde semikolon eller linjeskift. Brug Control API-operationerne til brugere, hvis dine værdier kræver et mere fleksibelt importformat.

1. Download og konfigurér Seed Tool til det ønskede miljø. Sæt SeedSettings.UsersSvcPath til den konverterede CSV-fil.
2. Kør Seed Tool, og vælg U for at masseuploade brugerne.
3. Registrér de nye bruger-ID'er i din migreringsoversigt.

Du kan afprøve uploaden med en CSV-fil med få brugere i et testmiljø. Seed Tool viser antallet af vellykkede og mislykkede importer. De importerede brugere kan gennemgås i FoxIDs Control, hvor du kan se deres identifikatorer, deaktiveringsstatus, claims og flag til oprettelse af adgangskode.

Seed Tool bruger masseprovisionering, som kan erstatte eksisterende brugere frem for at sammenflette dem. Gentagen upload kan fjerne legitimationsoplysninger og tilstand og oprette nye bruger-ID'er. Ved en delvist gennemført import afstemmes resultatet før et nyt forsøg; brug målrettede brugeropdateringer til senere ændringer.

Oprettelse af adgangskode ved første login

For en aktiveret, importeret bruger med SetPasswordEmail=true er det forventede flow:

1. Brugeren åbner applikationen og starter login gennem FoxIDs Login.
2. FoxIDs identificerer brugeren ud fra e-mailadressen og sender en bekræftelseskode.
3. Brugeren indsender koden og en ny adgangskode, der opfylder FoxIDs adgangskodepolitikken.
4. FoxIDs verificerer e-mailadressen, gemmer adgangskoden og nulstiller flagene for oprettelse af adgangskode. Login fortsætter gennem eventuelle påkrævede MFA-trin, før brugeren vender tilbage til applikationen.

Import af en bruger sender ikke opsætningsmailen. Efterfølgende login med adgangskode bruger den nye FoxIDs adgangskode. Hvis en bruger ikke kan modtage koden, kræver gendannelsesprocessen en anden måde at verificere identiteten på.

Du kan undersøge flowet med en testbruger ved at følge logintrinene ovenfor. Disse scenarier viser de forventede resultater:

Behold Okta under overgangen

FoxIDs kan have tillid til Okta som ekstern identitetsudbyder, mens applikationerne flyttes til FoxIDs. Brugerne autentificeres hos Okta, og FoxIDs udsteder tokens til applikationen. Okta adgangskoder og autentifikatorer forbliver dermed hos Okta; de kopieres ikke til FoxIDs.

For en OpenID Connect-forbindelse:

1. Opret en OIDC-webapplikationsintegration i Okta til FoxIDs med Authorization Code Flow. Tildel de brugere eller grupper, der skal logge ind gennem integrationen, og konfigurér dens loginpolitik.
2. Opret en OpenID Connect autentificeringsmetode i FoxIDs. Angiv den valgte Okta issuer som Authority, og konfigurér Okta klient-ID'et under Optional custom SP client ID, dets klienthemmelighed og den tilsvarende klientautentificeringsmetode til token-endpointet.
3. Anmod efter behov om scopes profile og email; FoxIDs medtager openid. Vælg Read claims from the UserInfo Endpoint instead of the access token or ID token under Show advanced for at hente brugerens claims via UserInfo.
4. Registrér den Redirect URL, FoxIDs viser, som redirect-URI til login i Okta, og konfigurér den tilsvarende redirect-URI til logout, hvor logout anvendes.
5. Tillad autentificeringsmetoden på FoxIDs applikationen, og konfigurér Home Realm Discovery for de brugere, der fortsætter gennem Okta.

Oktas org authorization server understøtter OpenID Connect-login med en issuer som https://example.okta.com. En brugerdefineret authorization server bruger en issuer som https://example.okta.com/oauth2/default. Brug den issuer og claimkonfiguration, der er valgt til integrationen.

En SAML-autentificeringsmetode er en anden mulighed: opret en SAML-applikation i Okta til FoxIDs, og udveksl metadata og indstillinger for tjenesteudbyderen og identitetsudbyderen.

Et testlogin gennem applikationen viser Okta autentificeringspolitik, claims, kontotilknytning og logoutadfærd for den nye forbindelse. Efterhånden som brugere flyttes til lokalt FoxIDs login eller direkte tilsluttede udbydere, routes de til disse autentificeringsmetoder. Når applikationens kontotilknytning er afstemt på tværs af metoderne, kan den fortsat bruge de samme kontoposter.

Rul ud og bevar mulighed for rollback

Migreringen kan udrulles pr. applikation eller brugergruppe. Brugerne kan fortsætte via deres sædvanlige applikations-URL med det konfigurerede loginforløb: oprettelse af adgangskode, engangskode, deres katalogadgangskode eller en ekstern identitetsudbyder.

Afstem brugere, som er oprettet, ændret, suspenderet eller slettet siden eksporten, herunder ændringer i grupper og applikationstildelinger. Et kort ændringsstop eller en kontrolleret afstemningsproces kan holde kilde og destination afstemt under overgangen. Senere opdateringer bør bevare legitimationsoplysninger og tilstand, som allerede er etableret i FoxIDs.

Overvåg levering af e-mail og SMS, fejl ved oprettelse af adgangskode, loginfejl og problemer med kontotilknytning. Tilbagerulning afhænger af, at den tidligere Okta konfiguration stadig er tilgængelig. Du kan afprøve gendannelse af den konfiguration for en testapplikation for at se overgangen tilbage til Okta loginforløbet.

En adgangskode oprettet lokalt i FoxIDs synkroniseres ikke tilbage til Okta. Tilbagerulning bruger derfor de legitimationsoplysninger, der stadig findes hos Okta eller den tilsluttede udbyder. Brugere, som kun er oprettet i FoxIDs, har brug for en adgangsvej ved tilbagerulning. Når de nødvendige brugere og applikationer anvender deres nye autentificeringsmetoder, kan Okta integrationen udfases.

Relateret dokumentation

• Oversigt over migrering
• Upload mange brugere
• Control API-operationer til brugere
• Login og Home Realm Discovery
• Directory Connector for Active Directory
• OpenID Connect autentificeringsmetode