En lösenordsmigrering är inte en databaskopiering. När användare flyttas mellan identitetsleverantörer kan källan ofta inte tillhandahålla ett lösenord som målet kan återanvända. Även om en export innehåller lösenordshashar är en hash som skapats för en plattform inte automatiskt giltig på en annan.
Användare kan ibland behålla sitt befintliga lösenord utan en tvingad återställning. Den säkra metoden beror på vad källan kan exportera, om den kan validera lösenord online, hur länge den kan vara tillgänglig och om migreringen kan koppla varje konto till ett stabilt käll-ID.
Den här artikeln ger en beslutsmodell för att välja mellan kompatibel import, gradvis lösenordsvalidering, fortsatt extern validering och en kontrollerad lösenordsåterställning. Fokus ligger på lösenordsspåret. Applikationsprotokoll, claims, registrering av multi-factor authentication (MFA) och den fullständiga cut-over-planen måste fortfarande hanteras som sammanhängande migreringsspår.
Börja med källan, inte den önskade användarupplevelsen
”Ingen lösenordsåterställning” är ett önskvärt resultat, men ännu ingen migreringsmetod. Innan ni väljer ett tillvägagångssätt måste ni fastställa vad källan faktiskt kan stödja:
- Kan den exportera lösenord i klartext eller en lösenordsrepresentation som målet uttryckligen stöder?
- Kan den validera användarens nuvarande lösenord via ett skyddat validerings-API?
- Kan detta API förbli tillgängligt, övervakat och supportat under en gradvis migrering och rollback-period?
- Finns det ett stabilt och oföränderligt käll-ID för användaren som kan binda samma konto över ändringar av identifierare?
- Kan lösenordsbyten och återställningar hållas konsekventa medan två system är involverade?
- Tillåter säkerhetspolicy, avtal och riskbedömning att lösenordsmaterial importeras eller behålls?
Använd inte e-postadress, telefonnummer eller användarnamn som enda migreringsnyckel. Dessa identifierare kan ändras. En felaktig kontokoppling är allvarligare än en återställning eftersom inloggningsuppgifter och åtkomst kan bindas till fel identitet.
Välj en av fyra lösenordsvägar
Olika användargrupper kan behöva olika vägar. Aktiva medarbetare kan till exempel migreras gradvis genom onlinevalidering, medan vilande externa konton får återställa lösenordet när de återkommer.
| Källans förmåga och begränsning | Försvarbar väg | Huvudsaklig fördel | Huvudsaklig kostnad eller risk |
|---|---|---|---|
| Lösenord eller en målkompatibel lösenordsrepresentation finns tillgängliga och kan hanteras säkert | Kontrollerad batchimport | Användare kan autentisera i målet direkt | Export, transport och behandling av lösenordsmaterial utökar säkerhetsgränsen |
| Källan kan validera befintliga lösenord online och förbli auktoritativ under övergången | Gradvis migrering med Directory Connector | Aktiva användare flyttas vid lyckad inloggning utan en gemensam återställning | Källan och connectorn förblir i produktionsflödet för authentication fram till cut-over |
| Användarna är redan etablerade i FoxIDs och endast lösenordsvalidering, policykontroll eller meddelande om ändringar förblir externt | External Password API | Behåller en smalare integration till lösenordslager eller policy | Ger inte samma flöde för att skapa användare och synkronisera profiler som Directory Connector |
| Varken säker kompatibel import eller tillförlitlig onlinevalidering finns | Verifierad lösenordsåterställning | Upprättar ett nytt lösenord i målet med en tydlig trust-gräns | Användarkommunikation, återställningskanaler och supportkapacitet blir avgörande |
Svaret är därför inte alltid ”bevara” eller alltid ”återställ”. Välj den minst störande väg som fortfarande kan försvaras tekniskt och operativt för varje användargrupp.
Gradvis migrering med Directory Connector
Directory Connector är det huvudsakliga mönstret i FoxIDs när ett befintligt directory eller anpassat repository måste förbli auktoritativt under övergången.
När en användare loggar in med lösenord anropar FoxIDs connectorns API. Efter en lyckad validering skapar eller uppdaterar FoxIDs den interna användaren från de returnerade identifierarna, egenskaperna och claims. Svaret innehåller ett stabilt directoryUserId som binder användaren i FoxIDs till källkontot även om användarens e-postadress, telefonnummer eller användarnamn senare ändras.
Detta skapar ett praktiskt just-in-time-flöde:
- Användaren loggar in i en applikation via FoxIDs med befintlig identifierare och lösenord.
- FoxIDs ber källans directory att validera lösenordet.
- Connectorn returnerar det stabila käll-ID:t och godkända användardata.
- FoxIDs skapar eller uppdaterar den interna användaren och slutför authentication.
- Användaren kan fortsätta med sitt befintliga lösenord så länge källan förblir auktoritativ.
Som standard sparar FoxIDs även en lokal lösenordskopia efter en lyckad validering eller lösenordslivscykelåtgärd via connectorn. Kopian ger möjlighet att senare planerat byta till lösenordsvalidering i FoxIDs utan att återställa lösenordet för alla användare som har slutfört det gradvisa flödet.
Gränsen är viktig: medan Directory Connector är aktiverad är det externa directoryt auktoritativt. FoxIDs använder inte den sparade lokala hashen som automatisk fallback om connectorn är otillgänglig. Ett avbrott i connectorn är därför ett fel i authentication-vägen, inte en instruktion att kringgå källan.
Inställningen för lösenordspolicy som visas nedan är ett tredje, oberoende beslut. Den styr om FoxIDs kontrollerar ett föreslaget lösenord mot miljöpolicyn i FoxIDs innan connectorn anropas. Det externa directoryt äger fortfarande lösenordet och kan avvisa det enligt sin egen policy. Om båda kontrollerna används måste krav och användarvägledning samordnas.
Definiera exit-kriterier innan connectorn aktiveras
En gradvis migrering behöver ett slutvillkor. Bestäm före utrullningen:
- Vilka användargrupper måste ha genomfört en lyckad inloggning före cut-over?
- Hur ska inaktiva konton eller konton vars användare aldrig återkommer hanteras?
- Hur länge måste källan och connectorn vara tillgängliga för rollback?
- Vilka svarstider och felfrekvenser i connectorn ska stoppa eller återställa utrullningen?
- Hur ska konflikter mellan identifierare, saknade claims och inaktiverade eller borttagna källkonton utredas?
- När kan connectorn inaktiveras och FoxIDs bli auktoritativt för lösenord?
Att spara en lokal kopia är valfritt. Inaktivera det när en policy kräver att källan förblir det enda lösenordslagret, men var medveten om att detta tar bort vägen till ett senare byte utan återställning.
När External Password API är den smalare lösningen
FoxIDs kan konfigurera ett External Password API som lösenordskontroll för interna användare. Det kan validera ett aktuellt lösenord, validera ett nytt lösenord mot en extern policy, meddela ett annat system om lösenordsändringar eller kombinera dessa ansvarsområden.
Använd detta alternativ när användarna redan finns i FoxIDs och det återstående behovet specifikt gäller lösenordslagret eller lösenordspolicyn. Betrakta det inte som en ersättning för Directory Connector när migreringen också kräver just-in-time-skapande av användare, en stabil bindning till ett externt directory, profiluppdateringar eller hantering av externa kontons livscykel.
Skillnaden håller integrationsgränsen tydlig: Directory Connector representerar ett auktoritativt externt directory. External Password API representerar ett externt beroende för lösenordsvalidering, policy eller aviseringar för interna användare.
När batchimport kan motiveras
Batchimport kan ta bort driftsberoendet av källan, men bara när indata passar målet och kan skyddas under hela överföringen.
FoxIDs stöder uppladdning av interna användare med kända lösenord, med förberäknade lösenordshashar som är kompatibla med FoxIDs eller utan lösenord. En hash från en godtycklig källplattform kan inte bara betecknas som en hash för FoxIDs. Bekräfta exakt algoritm, salt och målformat innan ni beslutar att en exporterad hash kan återanvändas.
Behandla export av lösenord i klartext som ett säkerhetsbeslut, inte som en bekvämlighet. Begränsa åtkomst, använd en kontrollerad överföringsväg, hindra lösenord från att hamna i loggar eller vanliga projektfiler, verifiera att tillfälligt material har raderats och dokumentera vem som godkände åtgärden. Om hanteringen inte kan motiveras ska ni i stället välja onlinevalidering eller återställning.
När lösenordsåterställning är säkrare
En återställning är inte nödvändigtvis ett tecken på en misslyckad migrering. Det är den ärliga vägen när bevarande av det befintliga lösenordet skulle försvaga målet eller bero på antaganden som teamet inte kan verifiera.
Föredra en kontrollerad återställning när:
- källan varken kan exportera en kompatibel representation eller validera det aktuella lösenordet online;
- överföring av lösenordsmaterial skulle skapa en oacceptabel exponering eller ett avtalsproblem;
- lösenordet i källan är känt eller misstänkt komprometterat;
- konton inte med tillräcklig säkerhet kan korreleras till stabila källidentiteter;
- källan inte kan förbli tillförlitlig under den nödvändiga perioden för gradvis migrering och rollback; eller
- bevarande av det gamla lösenordet skulle kräva svagare kontroller i målet.
Användare i FoxIDs kan laddas upp utan lösenord och uppmanas att ange ett med en verifieringskod som skickas via e-post eller SMS. Det är endast säkert när identifieraren för kontoåterställning tillhör rätt användare och leveranskanalen uppfyller organisationens riskkrav. Testa utgångna koder, otillgängliga inkorgar eller telefonnummer, dubbla identifierare, låsta konton och eskalering till support före en bred utrullning.
Kommunicera orsaken och tidpunkten innan användarna möter återställningen. Håll säkerhetsbeslutet åtskilt från supportplanen: en sund återställningsdesign kan fortfarande misslyckas operativt om återställningskanalerna är inaktuella eller servicedesk inte kan hantera den inledande belastningen.
Kräv bevis före cut-over för lösenord
Testa den valda vägen i en separat miljö i FoxIDs och flytta först en kontrollerad användargrupp. En lyckad inloggning är nödvändig men inte tillräcklig.
| Beslutsområde | Bevis som krävs före bredare utrullning |
|---|---|
| Identitetsbindning | Stabila käll-ID:n, testade ändringar av identifierare och definierad hantering av dubbletter eller saknade användare |
| Lösenordsbeteende | Godkända och avvisade lösenord, flöde för utgånget lösenord, lösenordsbyte/återställning och policyfel |
| Tillgänglighet | Övervakning av connector eller validerings-API, timeouts, felhantering och namngiven driftansvarig |
| Användarmigrering | Pilotresultat för representativa aktiva, inaktiva, avstängda och begränsade konton |
| Säkerhet | Godkänd hantering av lösenordsmaterial, skyddade secrets, diagnostisk loggning utan lösenord och granskad datalagring |
| Cut-over | Exit-kriterier per användargrupp, hantering av användare utan sparat mållösenord, rollback-trigger och ansvarig för avveckling av källan |
Behåll källan tills den nödvändiga användargruppen har migrerats och rollback-perioden har avslutats. Inaktivera inte connectorn bara för att piloten lyckades. Verifiera målets lösenordsväg för den population som måste fungera efter cut-over och behåll en kontrollerad återställningsväg för resten.
Så stöder FoxIDs beslutet
Använd dokumentationen om migrering för att planera applikationer, användare, lösenord, cut-over och rollback tillsammans. Dokumentationen om Directory Connector, External Password API och uppladdning av användare innehåller de exakta implementeringsdetaljerna.
Om källans förmågor, användargrupper eller cut-over-kriterier ännu inte är tydliga beskriver FoxIDs Identity Migration hur teamet bakom plattformen kan hjälpa till att utforma och genomföra migreringen.
Slutsats
Användare kan behålla ett befintligt lösenord endast när migreringen bevarar en tillförlitlig valideringsväg eller säkert etablerar ett kompatibelt mållösenord. Directory Connector ger ofta den minst störande gradvisa vägen, men håller också källan i produktionsflödet för authentication fram till en medveten cut-over.
Välj återställning när kompatibilitet, identitetsbindning eller säker hantering inte kan styrkas. Rätt lösenordsstrategi är den som gör den auktoritativa källan, felbeteendet, användarpåverkan och exit-kriterierna tydliga innan produktionstrafiken flyttas.