Migrering

Migrering til FoxIDs kombinerer normalt applikationsmigrering, brugermigrering og en kontrolleret overgang mellem den eksisterende identitetsplatform og FoxIDs. Planlæg disse arbejdsstrømme sammen, så identifikatorer, claims, autentificeringsadfærd og rollback-muligheder forbliver konsistente under hele overgangen.

FoxIDs tenants understøtter separate miljøer. Brug dedikerede udviklings-, test-, staging- og produktionsmiljøer til at konfigurere og validere migrationsflows parallelt uden at ændre produktionsmiljøet for tidligt.

Vurder den eksisterende identitetsplatform

Start med at kortlægge:

Applikationer, API'er og miljøer forbundet med den eksisterende platform.
Konfigurationer til OpenID Connect, OAuth 2.0, SAML 2.0 og WS-Federation.
Identitetsudbydere, autentificeringsmetoder og krav til multifaktorgodkendelse.
Brugeridentifikatorer, profiler, claims, grupper, roller og adgangstildelinger.
Kildeplatformens muligheder for lagring, validering og nulstilling af adgangskoder.
Certifikater, metadata, redirect-URL'er, logoutadfærd og tokenlevetider.
Overvågning, revision og tilbagerulningskrav for cut-over.

Kilden kan være AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID eller en anden identitetsudbyder eller brugerdefineret brugerlager. Den tilgængelige migreringssti afhænger af de protokoller, eksportfunktioner og adgangskodevalideringsmuligheder, der leveres af den pågældende kilde.

Applikationsmigrering

Migrer applikationer efter protokol og miljø i stedet for at behandle alle applikationer som én samlet cut-over.

Registrer applikationen i et ikke-produktions FoxIDs miljø.
Genskab de nødvendige claims, scopes, identifikatorer, certifikater og logoutadfærd.
Tilslut den eksisterende identitetsudbyder som en autentificeringsmetode, når parallel autentificering er nødvendig.
Test hele login-, token- og logout-flowet med repræsentative brugere og integrationer.
Flyt en kontrolleret gruppe eller én applikation ad gangen før en bredere udrulning.

FoxIDs protokolbro lader en applikation beholde sin nuværende protokol, mens identitetsudbyderens side ændres. Dette er nyttigt, når moderne OpenID Connect-applikationer og eksisterende SAML 2.0- eller WS-Federation-applikationer skal fungere i samme migreringsperiode.

Brugerprofiler og identifikatorer

Beslut hvilken identifikator der forbliver stabil, før du importerer eller opretter brugere. E-mailadresser, telefonnumre og brugernavne kan ændres, så brug en stabil kildeidentifikator, hvor integrationen understøtter en.

Kortlæg de krævede brugeroplysninger efter migrering:

Brugerprofilegenskaber og login-id'er.
Claims, som bruges af applikationer og API'er.
Grupper, roller og adgangstildelinger.
Krav til multifaktorgodkendelse samt fremgangsmåden for registrering eller gendannelse efter migrering.
Deaktiverede, slettede eller på anden måde begrænsede konti.

Brug Upload mange brugere, når brugere kan eksporteres og importeres i batches. Brug Directory Connector, når en eksisterende directory eller et brugerdefineret repository skal forblive autoritativt under overgangen. Til Active Directory skal du bruge Directory Connector for Active Directory.

Adgangskodestrategi

Vælg adgangskodestrategi ud fra, hvad kildeplatformen kan eksportere eller validere sikkert:

Importér kun adgangskoder eller understøttede password hashes, når de er tilgængelige i et kompatibelt format og kan håndteres sikkert.
Valider den eksisterende adgangskode via Directory Connector, mens source directory forbliver autoritativt.
Som standard gemmer FoxIDs en lokal kopi af adgangskoden efter en vellykket validering via Directory Connector. Det gør det muligt senere at deaktivere connectoren og flytte adgangskodevalideringen til FoxIDs uden at tvinge alle brugere gennem en nulstilling.
Deaktiver den lokale adgangskodekopi, når politikken kræver, at den eksterne mappe forbliver det eneste adgangskodelager.
Kræv nulstilling af adgangskode, når det ikke er teknisk muligt at importere eller bevare den eksisterende adgangskode, eller når nulstilling er den sikreste mulighed.

Antag aldrig, at adgangskoder kan flyttes direkte fra en identitetsudbyder. Bekræft kildeplatformens eksportformat, hashing-algoritme, validerings-API og sikkerhedsbegrænsninger, før du vælger migreringsmetoden.

Gradvis migrering

Når source directory understøtter onlinevalidering, kan brugere oprettes eller opdateres i FoxIDs ved deres første vellykkede login via Directory Connector. Det understøtter en gradvis overgang uden at kræve, at alle brugere migreres samtidigt.

Hold kilden tilgængelig, indtil den nødvendige brugergruppe er migreret, og rollback-vinduet er lukket. Overvåg mislykkede logins, identifikatorkonflikter, manglende claims og connectorens tilgængelighed under hele overgangen.

Cut-over og rollback

Før cut-over til produktion:

Gennemfør repræsentative applikations- og brugeraccepttests.
Bekræft certifikater, metadata, DNS, omdirigerings-URL'er og firewallstier.
Definer rækkefølgen, som applikationer, API'er og brugergrupper flytter i.
Registrer den tidligere konfiguration og de betingelser, der udløser rollback.
Sørg for, at overvågning og logning dækker både FoxIDs og de resterende flows gennem kildeplatformen.
Kommuniker nulstilling af adgangskode eller ændret login-adfærd, før det påvirker brugerne.

En trinvis udrulning begrænser antallet af applikationer og brugere, der påvirkes af hver ændring. Bevar muligheden for rollback, indtil produktionsadfærd, claims og adgang er verificeret.