Migrer fra Okta til FoxIDs

Flytt pålogginger fra Okta til FoxIDs med migreringsmetoden som passer hvor hver brukergruppe autentiseres. Importer lokale brukere og la dem velge et nytt passord, eller aktiver passordfri pålogging med engangskoder. For sosiale pålogginger og bedriftspålogginger konfigurerer du autentiseringsmetoder i FoxIDs som stoler på eksterne identitetsleverandører. Okta kan også fortsatt være identitetsleverandør mens applikasjonene flyttes til FoxIDs.

Denne tekniske veiledningen dekker brukere i Okta Universal Directory, applikasjonskonfigurasjon og kontotilknytning for Okta Identity Engine og Classic Engine.

For import av lokale brukere konverterer du den gjennomgåtte eksporten fra Okta til en CSV-fil og bruker FoxIDs Seed Tool til å masselaste brukerne inn i FoxIDs. CSV-eksemplene nedenfor viser feltene for passordoppsett og passordfri pålogging.

Velg en fremgangsmåte for hver gruppe:

Forbered målet og applikasjonen

Et eget testmiljø lar deg prøve migreringen med en liten brukergruppe før produksjon. Konfigurasjonstrinnene er:

1. Hvis du ønsker et egendefinert domene, konfigurerer og verifiserer du det på leieren før du konfigurerer applikasjoner og eksterne identitetsleverandører. Bruk de resulterende FoxIDs URL-ene gjennom hele migreringen. Endring av domenet senere krever oppdatering av eksterne konfigurasjoner, inkludert applikasjonenes authority- eller metadata-URL-er og leverandørenes callback- og utloggings-URL-er.
2. Hvert miljø har en standard Login-autentiseringsmetode kalt login. Tilpass merkevarebygging og påloggingsgrensesnitt til ønsket utseende, og juster påloggingsalternativene for de importerte brukerne.
3. Opprett autentiseringsmetodene som kobler brukerne til eksterne identitetsleverandører, inkludert Okta hvis det fortsatt inngår i overgangen.
4. Konfigurer applikasjonen, tillatte omdirigerings-URL-er og utloggingsatferd samt eventuelle API-er som godtar tilgangstokenene.

FoxIDs Cloud tilbyr levering av e-post og SMS for passordoppsett, passordfri pålogging og flerfaktorautentisering (MFA), avhengig av valgt FoxIDs Cloud abonnement.

Konfigurer nødvendige MFA-innstillinger og hvordan brukerne skal registrere seg. CSV-importene beskrevet her overfører brukerdata, ikke registreringer i Okta Verify, enhetsregistreringer i FastPass, passnøkler eller andre MFA-registreringer. Brukere som autentiseres lokalt i FoxIDs, registrerer de konfigurerte autentiseringsfaktorene. Brukere som fortsatt autentiseres gjennom Okta, kan beholde registreringene der.

Applikasjonskonfigurasjon er et eget arbeid ved siden av brukerimport. Gjennomgå utsteder, målgruppe, scopes, claims og tokenvalidering samt eventuelle avhengigheter av Okta SDK eller Sign-In Widget, inline hooks, grupperegler og applikasjonstildelinger. Gjenskap atferden applikasjonen trenger. Den generelle migreringsveiledningen dekker den samlede applikasjonsoversikten og utrullingstrinnene.

Eksporter en definert gruppe Okta brukere

Bruk Okta Users API til å hente brukerdata som JSON for konvertering. Velg kildeorganisasjonen og brukerne eller gruppene som skal migreres. Følg URL-en for rel="next" i svarhodet Link til alle sider er lest. Den vanlige listeoperasjonen utelater DEPROVISIONED-brukere; en filter- eller søkespørring kan inkludere dem. Søkeresultater er etter hvert konsistente, så nylige endringer kan ta tid før de vises.

Behold kildeorganisasjonen og brukerens id, livssyklusens status, nødvendige profile-attributter og informasjon om credentials.provider. Hold brukere administrert av Okta, katalogbaserte brukere og fødererte brukere atskilt. Identitetsleverandørkonfigurasjon og rutingsregler bidrar til å identifisere hvor brukerne faktisk autentiseres.

For rapportbasert eksport har User Accounts-rapporten alternativet CSV Export. Kolonnene må fortsatt konverteres til FoxIDs Seed Tools format. API-et er nyttig når importen også trenger egendefinerte attributter eller leverandørinformasjon som mangler i rapporten.

Eksporter gruppemedlemskap og applikasjonstilgang separat når de avgjør rettigheter. Oktas Group Membership-rapport og User App Access-rapport beskriver disse forholdene; de finnes ikke alle i brukerens profile-objekt.

Tilgjengelighet av passord

Okta tilbyr bare eksport av passordhasher for migrering til Auth0, under bestemte forutsetninger.

FoxIDs kan importere støttede passordhasher når de er tilgjengelige.

Tilordne brukerdata og bevar applikasjonskontoer

FoxIDs oppretter sin egen varige bruker-ID for importerte lokale brukere. Import av Okta brukerens id som et egendefinert claim gjør den ikke til brukerens FoxIDs ID og bevarer ikke automatisk applikasjonens subject. Registrer faktisk OpenID Connect sub eller SAML NameID brukt av hver applikasjon sammen med kildeorganisasjon og bruker-ID.

Hvis applikasjonen bruker Okta brukerens ID som sub, importerer du denne ID-en som et egendefinert claim, for eksempel legacy_okta_user_id. På Login-autentiseringsmetoden konfigurerer du en Map claim-transformasjon med handlingen Replace claim, inndataclaim legacy_okta_user_id og utdataclaim sub. Applikasjonen mottar da verdien som sub, mens brukerens varige FoxIDs ID forblir uendret. Hvis applikasjonen bruker en annen subject-verdi, bevarer og tilordner du den verdien i stedet.

Applikasjoner som identifiserer kontoer med både utsteder og subject, må også knytte den nye FoxIDs utstederen til eksisterende kontoer. For SAML applikasjoner konfigurerer du nødvendig NameID og format på SAML applikasjonsregistreringen. En testpålogging viser den faktiske identiteten som applikasjonen mottar.

Oppretthold en tilordning mellom kildeidentiteten, den nye FoxIDs identiteten og den eksisterende applikasjonskontoen. Identitetene brukt under overgangen bør vise til samme kunde- eller medarbeiderpost. For sosiale pålogginger og bedriftspålogginger inkluderer du identiteten mottatt direkte fra leverandøren; den kan avvike fra Okta brukerens ID.

For import av lokale brukere bruker du følgende tilordning:

Oktas livssyklusstatuser er mer detaljerte enn FoxIDs deaktiveringsflagg. Eksemplene aktiverer brukere valgt fra ACTIVE-kontoer og holder suspenderte kontoer deaktivert. Statuser som STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED og LOCKED_OUT trenger uttrykkelig tilordning til ønsket atferd for aktivering, passordoppsett eller tilgang.

Migrer sosiale pålogginger og bedriftspålogginger

Opprett en autentiseringsmetode i FoxIDs for hver sosial identitetsleverandør eller bedriftsleverandør som nå er tilkoblet gjennom Okta, med direkte tillit til leverandøren. Brukerne beholder kontoene og påloggingsopplysningene hos leverandøren.

1. Identifiser leverandøren bak hver tilkobling. Bruk relevant integrasjonsveiledning for leverandøren, for eksempel Google eller Microsoft Entra ID, og velg en støttet autentiseringsmetode for OpenID Connect, SAML 2.0 eller WS-Federation.
2. Registrer eller konfigurer FoxIDs hos leverandøren. Utveksle klientinnstillinger eller føderasjonsmetadata og konfigurer callback- og utloggings-URL-ene angitt i integrasjonsveiledningen. Behold Okta tilkoblingen under overgangen.
3. Tillat den nye autentiseringsmetoden på applikasjonen i FoxIDs. Konfigurer Home Realm Discovery slik at brukerne kan velge leverandør eller rutes dit av konfigurerte regler.
4. Tilordne leverandøridentiteten til den eksisterende applikasjonskontoen. Hvis du trenger å lagre claims eller tilgangstildelinger per bruker i FoxIDs, konfigurerer og klargjør du eksterne brukere.
5. Gjenskap tilgangsbegrensninger som Okta tidligere håndhevet, inkludert applikasjonstildelinger, suspenderte brukere og påkrevd MFA.

Forventet flyt er applikasjon → FoxIDs → ekstern identitetsleverandør → FoxIDs → applikasjon. FoxIDs utsteder applikasjonens tokener etter at leverandøren autentiserer brukeren.

Du kan prøve hver tilkobling ved å starte pålogging fra applikasjonen, velge leverandøren og fullføre påloggingsflyten. Da kan du observere MFA, applikasjonskonto og rettigheter samt utloggingsatferd.

Migrer brukere fra Active Directory

Hvis Okta delegerer passordautentisering til Active Directory og AD fortsatt er kilden, kan FoxIDs koble direkte til gjennom Directory Connector for Active Directory. Konfigurer connectoren og Login-autentiseringsmetoden som beskrevet i den veiledningen. FoxIDs synkroniserer brukere fra AD og validerer passord mot AD, så disse brukerne trenger ingen passordimport via CSV.

Som standard lagrer FoxIDs en lokal passordkopi etter vellykket validering med Directory Connector. Dette støtter senere overgang til lokal autentisering i FoxIDs ved å deaktivere connectoren. Brukere som ikke har fått passordet registrert, kan bruke passordoppsett. Se Directory Connectors passordatferd for konfigurasjonsvalg.

En bruker i Okta med AD som kilde autentiseres ikke nødvendigvis fortsatt mot AD: Okta kan migrere passordautentisering fra AD til Okta. Direkte tilkobling med connectoren gjelder når AD fortsatt lagrer og validerer passordet brukeren benytter.

Migrer passordfrie brukere

Importer brukere som interne FoxIDs brukere uten passord og konfigurer passordfri pålogging med e-post- eller SMS-kode. Brukeren oppgir koden på påloggingssiden som allerede er åpnet.

Dette endrer autentiseringsmetoden for brukere av Okta FastPass eller passkeys. E-post- og SMS-koder gir ikke samme motstand mot phishing som FastPass.

1. Aktiver e-post eller telefon som påloggingsidentifikator på autentiseringsmetoden FoxIDs Login, og aktiver Passwordless with email (one-time password) eller Passwordless with SMS (one-time password) etter behov.
2. For en påloggingsmetode beregnet på passordfrie brukere velger du Disable password authentication og deaktiverer passordoppsett/tilbakestilling via e-post og SMS.
3. Importer brukerne uten Password og alle passordhashfelt. La SetPasswordEmail, SetPasswordSms og ChangePassword være false. Bevar tilordnet verifiseringsstatus, deaktiveringsstatus og nødvendige claims.

Denne CSV-filen for Seed Tool importerer for eksempel en fiktiv bruker med passordfri e-postpålogging og ukjent tidligere e-postverifiseringsstatus:

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

For SMS-brukere erstatter du Email og EmailVerified med Phone og PhoneVerified, med valgt telefonnummer og kjent verifiseringsstatus. Samme opplastingsprosedyre gjelder.

Du kan prøve flyten med en importert testbruker ved å oppgi e-postadressen eller telefonnummeret og mottatt kode. En gyldig kode lar en aktivert bruker fortsette gjennom eventuell påkrevd MFA til applikasjonen. Brukeren forblir uten passord etter vellykket passordfri pålogging.

Importer brukere for passordoppsett

Aktiver e-postpålogging, passordautentisering og passordoppsett via e-post på autentiseringsmetoden FoxIDs Login. Importerte brukere velger et passord under sin første pålogging.

Brukerimporten forbereder kontoene. Passordoppsett skjer når hver bruker starter en pålogging, ikke under importen.

Konverter de gjennomgåtte postene til en UTF-8-fil for FoxIDs Seed Tool. Kolonneoverskriftene skiller mellom store og små bokstaver, og skilletegnet er semikolon. Eksemplet inneholder fiktive brukere med ukjent tidligere e-postverifiseringsstatus; den andre kontoen forblir deaktivert:

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 velger passordoppsett med e-postbekreftelse. Utelat Password og alle passordhashkolonner. RequireMultiFactor=true er eksemplets valgte policy og krever at tilsvarende MFA-metoder konfigureres.

Utlever bare eksemplets claim legacy_okta_user_id til applikasjoner som trenger det gjennom sin konfigurerte claim-håndtering.

Last opp brukere og kontroller resultatet

Bruk denne opplastingsprosedyren for passordfrie brukere og brukere som skal velge et passord ved første pålogging, med feltene som passer valgt metode.

Seed Tool deler felt ved semikolon; felt i anførselstegn kan ikke inneholde semikolon eller linjeskift. Bruk Control APIs brukeroperasjoner hvis verdiene trenger en rikere importrepresentasjon.

1. Last ned og konfigurer Seed Tool for ønsket miljø. Sett SeedSettings.UsersSvcPath til den konverterte CSV-filen.
2. Kjør Seed Tool og velg U for å masselaste opp brukerne.
3. Registrer de nye bruker-ID-ene i migreringstilordningen.

Du kan prøve opplastingen med en CSV-fil med noen få brukere i et testmiljø. Seed Tool rapporterer antall vellykkede og mislykkede operasjoner. De importerte brukerne kan undersøkes i FoxIDs Control for å se identifikatorer, deaktiveringsstatus, claims og passordoppsettflagg.

Seed Tool bruker masseklargjøring som kan erstatte eksisterende brukere i stedet for å slå dem sammen. Gjentatt opplasting kan fjerne påloggingsopplysninger og tilstand og opprette nye bruker-ID-er. Ved delvis fullført import avstemmer du resultatet før du prøver igjen; bruk målrettede brukeroppdateringer for senere endringer.

Passordoppsett ved første pålogging

For en aktivert importert bruker med SetPasswordEmail=true er forventet flyt:

1. Brukeren åpner applikasjonen og starter pålogging gjennom FoxIDs Login.
2. FoxIDs identifiserer brukeren fra e-postadressen og sender en bekreftelseskode.
3. Brukeren sender inn koden og et nytt passord som oppfyller FoxIDs passordpolicy.
4. FoxIDs verifiserer e-postadressen, lagrer passordet og nullstiller passordoppsettflaggene. Påloggingen fortsetter gjennom eventuelle påkrevde MFA-trinn før brukeren returnerer til applikasjonen.

Import av en bruker sender ikke e-postmeldingen for passordoppsett. Senere passordpålogginger bruker det nye FoxIDs passordet. Hvis en bruker ikke kan motta koden, trenger gjenopprettingsprosessen en annen måte å verifisere identiteten på.

Du kan utforske flyten med en testbruker ved å følge påloggingstrinnene ovenfor. Disse scenariene viser forventede resultater:

Behold Okta under overgangen

FoxIDs kan stole på Okta som ekstern identitetsleverandør mens applikasjonene flyttes til FoxIDs. Brukerne autentiseres hos Okta, og FoxIDs utsteder tokener til applikasjonen. Dette beholder Oktas passord og autentiseringsmidler hos Okta; de kopieres ikke til FoxIDs.

For en OpenID Connect tilkobling:

1. Opprett en OIDC webapplikasjonsintegrasjon i Okta for FoxIDs med Authorization Code Flow. Tildel brukerne eller gruppene som skal logge på gjennom integrasjonen, og konfigurer påloggingspolicyen.
2. Opprett en OpenID Connect autentiseringsmetode i FoxIDs. Sett Authority til valgt Okta utsteder, og konfigurer Oktas klient-ID under Optional custom SP client ID, klienthemmeligheten og tilsvarende klientautentiseringsmetode for tokenendepunktet.
3. Be om scopes profile og email etter behov; FoxIDs inkluderer openid. Velg Read claims from the UserInfo Endpoint instead of the access token or ID token under Show advanced for å hente brukerens claims gjennom UserInfo.
4. Registrer Redirect URL vist av FoxIDs som omdirigerings-URI for pålogging i Okta, og konfigurer tilsvarende utloggings-URI der utlogging brukes.
5. Tillat autentiseringsmetoden på applikasjonen i FoxIDs og konfigurer Home Realm Discovery for brukerne som fortsetter gjennom Okta.

Oktas organisasjonsautorisasjonsserver støtter OpenID Connect pålogging med en utsteder som https://example.okta.com. En egendefinert autorisasjonsserver bruker en utsteder som https://example.okta.com/oauth2/default. Bruk utstederen og claim-konfigurasjonen valgt for integrasjonen.

En SAML autentiseringsmetode er et annet alternativ: opprett en SAML applikasjon i Okta for FoxIDs og utveksle metadata og innstillinger for tjenesteleverandør og identitetsleverandør.

En testpålogging gjennom applikasjonen viser Oktas autentiseringspolicy, claims, kontotilordning og utloggingsatferd for den nye tilkoblingen. Når brukerne går over til lokal pålogging i FoxIDs eller direkte tilkoblede leverandører, ruter du dem til disse autentiseringsmetodene. Samstemt kontotilordning på tvers av metodene lar applikasjonen fortsette å bruke de samme kontopostene.

Rull ut og behold en vei tilbake

Migreringen kan rulles ut per applikasjon eller brukergruppe. Brukerne kan fortsette via sin vanlige applikasjons-URL med konfigurert påloggingsflyt: passordoppsett, en engangskode, katalogpassordet eller en ekstern identitetsleverandør.

Avstem brukere opprettet, endret, suspendert eller slettet siden eksporten, inkludert endringer i grupper og applikasjonstildelinger. En kort endringsfrys eller kontrollert avstemmingsprosess kan holde kilde og mål samordnet under overgangen. Senere oppdateringer bør bevare påloggingsopplysninger og tilstand som allerede er etablert i FoxIDs.

Overvåk levering av e-post og SMS, oppsettfeil, påloggingsfeil og problemer med kontotilordning. Tilbakerulling avhenger av at den tidligere Okta konfigurasjonen fortsatt er tilgjengelig. Du kan prøve å gjenopprette konfigurasjonen for en testapplikasjon for å observere returen til påloggingsflyten i Okta.

Et passord angitt lokalt i FoxIDs synkroniseres ikke tilbake til Okta. En tilbakerulling bruker derfor påloggingsopplysningene som fortsatt finnes hos Okta eller tilkoblet leverandør. Brukere opprettet bare i FoxIDs trenger en tilgangsvei hvis tilbakerulling blir nødvendig. Når nødvendige brukere og applikasjoner benytter sine målrettede autentiseringsmetoder, kan Okta integrasjonen avvikles.

Relatert dokumentasjon

• Migreringsoversikt
• Last opp mange brukere
• Control APIs brukeroperasjoner
• Pålogging og Home Realm Discovery
• Directory Connector for Active Directory
• OpenID Connect autentiseringsmetode