Migrering

Migrering till FoxIDs kombinerar normalt applikationsmigrering, användarmigrering och en kontrollerad övergång mellan den befintliga identitetsplattformen och FoxIDs. Planera dessa arbetsflöden tillsammans så att identifierare, claims, autentiseringsbeteende och återställningsalternativ förblir konsekventa under hela övergången.

FoxIDs hyresgäster stöder separata miljöer. Använd dedikerade utvecklings-, test-, iscensättnings- och produktionsmiljöer för att konfigurera och validera migreringsflöden parallellt utan att ändra produktionsmiljön i förtid.

Bedöm den befintliga identitetsplattformen

Börja med att spela in:

Applikationer, API:er och miljöer kopplade till den befintliga plattformen.
OpenID Connect, OAuth 2.0, SAML 2.0 och WS-Federation-konfigurationer.
Identitetsleverantörer, autentiseringsmetoder och flerfaktorsautentiseringskrav.
Användaridentifierare, profiler, claims, grupper, roller och åtkomsttilldelningar.
Lösenordslagring, validering och återställningsalternativ tillgängliga i källplattformen.
Certifikat, metadata, omdirigeringsadresser, utloggningsbeteende och tokenlivslängder.
Övervakning, revision och återställningskrav för cut-over.

Källan kan vara AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID eller annan identitetsleverantör eller anpassat användarlager. Den tillgängliga migreringsvägen beror på de protokoll, exportmöjligheter och alternativ för lösenordsvalidering som tillhandahålls av den källan.

Programmigrering

Migrera applikationer enligt protokoll och miljö snarare än att behandla dödsboet som en enda cut-over.

Registrera applikationen i en icke-produktionsmiljö med FoxIDs.
Reproducera de påståenden, omfattningar, identifierare, certifikat och utloggningsbeteende som krävs.
Anslut den befintliga identitetsleverantören som en autentiseringsmetod när parallell autentisering krävs.
Testa hela inloggnings-, token- och utloggningsflödet med representativa användare och integrationer.
Flytta en kontrollerad grupp eller en applikation i taget innan en bredare lansering.

FoxIDs protokollöverbryggning låter en applikation behålla sitt nuvarande protokoll medan identitetsleverantörens sida ändras. Detta är användbart när moderna OpenID Connect-applikationer och befintliga SAML 2.0- eller WS-Federation-applikationer måste fungera under samma migreringsperiod.

Användarprofiler och identifierare

Bestäm vilken identifierare som förblir stabil innan du importerar eller skapar användare. E-postadresser, telefonnummer och användarnamn kan ändras, så använd en stabil källidentifierare där integrationen stöder en.

Kartlägg användarinformationen som krävs efter migreringen:

Användarprofilegenskaper och inloggningsidentifierare.
Påståenden som används av applikationer och API:er.
Grupper, roller och åtkomstuppdrag.
Krav på multifaktorautentisering och registrerings- eller återställningsmetoden efter migrering.
Inaktiverade, raderade eller på annat sätt begränsade konton.

Använd Ladda upp många användare när användare kan exporteras och importeras i partier. Använd Directory Connector när en befintlig katalog eller anpassad lagringsplats ska förbli auktoritativ under övergången. För Active Directory, använd Directory Connector for Active Directory.

Lösenordsstrategi

Välj lösenordssökvägen baserat på vad källplattformen kan exponera eller validera säkert:

Importera lösenord eller lösenordshashar som stöds endast när de är tillgängliga i en kompatibel form och kan hanteras säkert.
Validera det befintliga lösenordet via Directory Connector medan källkatalogen förblir auktoritativ.
Som standard sparar FoxIDs en lokal lösenordskopia efter framgångsrik validering av Directory Connector. Detta gör det möjligt att inaktivera anslutningen senare och flytta lösenordsvalidering till FoxIDs utan att tvinga varje användare genom en återställning.
Inaktivera den lokala lösenordskopieringen när policyn kräver att den externa katalogen förblir det enda lösenordsarkivet.
Kräv lösenordsåterställning när det inte är tekniskt möjligt att importera eller behålla det befintliga lösenordet eller när återställning är det säkrare alternativet.

Anta aldrig att lösenord kan flyttas direkt från en identitetsleverantör. Bekräfta källplattformens exportformat, hashalgoritm, validerings-API och säkerhetsbegränsningar innan du väljer migreringsmetod.

Gradvis migrering

Där källkatalogen stöder onlinevalidering, kan användare skapas eller uppdateras i FoxIDs vid deras första lyckade inloggning via Directory Connector. Detta stöder en gradvis övergång utan att alla användare måste migrera samtidigt.

Håll källan tillgänglig tills den önskade användarpopulationen har migrerat och återställningsfönstret har stängts. Övervaka misslyckade inloggningar, identifierarkonflikter, saknade claims och anslutartillgänglighet under hela övergången.

Cut-over och rollback

Före produktionsstopp:

Komplettera representativa applikations- och användaracceptanstest.
Bekräfta certifikat, metadata, DNS, omdirigeringsadresser och brandväggsvägar.
Definiera i vilken ordning applikationer, API:er och användargrupper flyttas.
Registrera den tidigare konfigurationen och de villkor som utlöser återställning.
Se till att övervakning och loggning täcker både FoxIDs och återstående källplattformsflöden.
Kommunicera lösenordsåterställning eller ändrat inloggningsbeteende innan det påverkar användare.

En utrullning i etapper begränsar antalet applikationer och användare som påverkas av varje ändring. Behåll återställning tekniskt möjligt tills produktionsbeteende, claims och åtkomst har verifierats.