En passordmigrering er ikke en databasekopiering. Når brukere flyttes mellom identitetsleverandører, kan kilden ofte ikke levere et passord som målet kan bruke på nytt. Selv om en eksport inneholder passordhasher, er en hash som er laget for én plattform, ikke automatisk gyldig på en annen.
Brukere kan noen ganger beholde sitt eksisterende passord uten en tvungen tilbakestilling. Den sikre metoden avhenger av hva kilden kan eksportere, om den kan validere passord på nett, hvor lenge den kan være tilgjengelig, og om migreringen kan knytte hver konto til en stabil kilde-ID.
Denne artikkelen gir en beslutningsmodell for å velge mellom kompatibel import, gradvis passordvalidering, fortsatt ekstern validering og en kontrollert passordtilbakestilling. Den fokuserer på passordløpet. Applikasjonsprotokoller, claims, registrering av multi-factor authentication (MFA) og den fullstendige cut-over-planen må fortsatt håndteres som sammenhengende migreringsspor.
Start med kilden, ikke den ønskede brukeropplevelsen
«Ingen passordtilbakestilling» er et ønskelig resultat, men ennå ikke en migreringsmetode. Før dere velger en fremgangsmåte, må dere fastslå hva kilden faktisk kan støtte:
- Kan den eksportere passord i klartekst eller en passordrepresentasjon som målet uttrykkelig støtter?
- Kan den validere brukerens nåværende passord gjennom et beskyttet validerings-API?
- Kan dette API-et forbli tilgjengelig, overvåket og støttet gjennom en gradvis migrering og rollback-periode?
- Finnes det en stabil og uforanderlig kilde-ID for brukeren som kan binde samme konto sammen på tvers av endringer i identifikatorer?
- Kan passordendringer og tilbakestillinger holdes konsistente mens to systemer er involvert?
- Tillater sikkerhetspolicy, avtaler og risikovurdering at passordmateriale importeres eller beholdes?
Ikke bruk e-postadresse, telefonnummer eller brukernavn som eneste migreringsnøkkel. Disse identifikatorene kan endres. En feilaktig kontokobling er mer alvorlig enn en tilbakestilling fordi påloggingsopplysninger og tilgang kan knyttes til feil identitet.
Velg én av fire passordveier
Ulike brukergrupper kan trenge ulike veier. Aktive ansatte kan for eksempel migreres gradvis gjennom nettbasert validering, mens sovende eksterne kontoer får en tilbakestilling når de kommer tilbake.
| Kildens mulighet og begrensning | Forsvarlig vei | Hovedfordel | Hovedkostnad eller risiko |
|---|---|---|---|
| Passord eller en målkompatibel passordrepresentasjon er tilgjengelig og kan håndteres sikkert | Kontrollert batchimport | Brukere kan autentisere i målet umiddelbart | Eksport, transport og behandling av passordmateriale utvider sikkerhetsgrensen |
| Kilden kan validere eksisterende passord på nett og forbli autoritativ under overgangen | Gradvis migrering med Directory Connector | Aktive brukere flyttes ved vellykket innlogging uten en samlet tilbakestilling | Kilden og connectoren forblir i produksjonsløpet for authentication frem til cut-over |
| Brukerne er allerede etablert i FoxIDs, og bare passordvalidering, policykontroll eller varsling om endringer forblir eksternt | External Password API | Beholder en smalere integrasjon mot passordlager eller policy | Gir ikke samme løp for brukeropprettelse og profilsynkronisering som Directory Connector |
| Verken sikker kompatibel import eller pålitelig nettbasert validering finnes | Verifisert passordtilbakestilling | Etablerer et nytt passord i målet med en tydelig trust-grense | Brukerkommunikasjon, gjenopprettingskanaler og supportkapasitet blir avgjørende |
Svaret er derfor ikke alltid «bevar» eller alltid «tilbakestill». Velg den minst forstyrrende veien som fortsatt kan forsvares teknisk og driftsmessig for hver brukergruppe.
Gradvis migrering med Directory Connector
Directory Connector er det viktigste FoxIDs mønsteret når en eksisterende katalog eller et tilpasset repository må forbli autoritativt under overgangen.
Når en bruker logger inn med passord, kaller FoxIDs connector API-et. Etter vellykket validering oppretter eller oppdaterer FoxIDs den interne brukeren fra identifikatorene, egenskapene og claims som returneres. Svaret inneholder et stabilt directoryUserId som knytter brukeren i FoxIDs til kildekontoen, selv om brukerens e-postadresse, telefonnummer eller brukernavn senere endres.
Dette gir et praktisk just-in-time-løp:
- Brukeren logger inn i en applikasjon gjennom FoxIDs med eksisterende identifikator og passord.
- FoxIDs ber kildekatalogen validere passordet.
- Connectoren returnerer den stabile kilde-ID-en og godkjente brukerdata.
- FoxIDs oppretter eller oppdaterer den interne brukeren og fullfører authentication.
- Brukeren kan fortsette med eksisterende passord så lenge kilden forblir autoritativ.
Som standard lagrer FoxIDs også en lokal passordkopi etter vellykket connectorvalidering eller en passordlivssyklushandling gjennom connectoren. Kopien gir mulighet til senere å bytte planlagt til passordvalidering i FoxIDs uten å tilbakestille passordet for alle brukere som har fullført det gradvise løpet.
Grensen er viktig: Mens Directory Connector er aktivert, er den eksterne katalogen autoritativ. FoxIDs bruker ikke den lagrede lokale hashen som automatisk fallback hvis connectoren er utilgjengelig. Et avbrudd i connectoren er derfor en feil i authentication-løpet, ikke en instruksjon om å omgå kilden.
Innstillingen for passordpolicy som vises nedenfor, er en tredje, uavhengig beslutning. Den styrer om FoxIDs kontrollerer et foreslått passord mot policyen i FoxIDs miljøet før connectoren kalles. Den eksterne katalogen eier fortsatt passordet og kan avvise det i henhold til sin egen policy. Hvis begge kontrollene brukes, må krav og brukerveiledning samordnes.
Definer exit-kriterier før connectoren aktiveres
En gradvis migrering trenger en sluttbetingelse. Bestem før utrullingen:
- Hvilke brukergrupper må ha fullført en vellykket innlogging før cut-over?
- Hvordan skal inaktive kontoer eller kontoer der brukeren aldri kommer tilbake, håndteres?
- Hvor lenge må kilden og connectoren være tilgjengelige for rollback?
- Hvilke svartider og feilrater i connectoren skal stoppe eller reversere utrullingen?
- Hvordan skal konflikter mellom identifikatorer, manglende claims og deaktiverte eller slettede kildekontoer undersøkes?
- Når kan connectoren deaktiveres og FoxIDs bli autoritativ for passord?
Lagring av en lokal kopi er valgfritt. Deaktiver dette når en policy krever at kilden forblir det eneste passordlageret, men vær klar over at dette fjerner veien til et senere bytte uten tilbakestilling.
Når External Password API er den smalere løsningen
FoxIDs kan konfigurere et External Password API som passordkontroll for interne brukere. Det kan validere et gjeldende passord, validere et nytt passord mot en ekstern policy, varsle et annet system om passordendringer eller kombinere disse ansvarsområdene.
Bruk dette alternativet når brukerne allerede finnes i FoxIDs og det gjenstående behovet spesifikt gjelder passordlageret eller passordpolicyen. Ikke behandle det som en erstatning for Directory Connector når migreringen også krever just-in-time-brukeropprettelse, en stabil binding til en ekstern katalog, profiloppdateringer eller håndtering av eksterne kontoers livssyklus.
Forskjellen holder integrasjonsgrensen tydelig: Directory Connector representerer en autoritativ ekstern katalog. External Password API representerer en ekstern avhengighet for passordvalidering, policy eller varsling for interne brukere.
Når batchimport kan forsvares
Batchimport kan fjerne driftsavhengigheten av kilden, men bare når inndataene er egnet for målet og kan beskyttes gjennom hele overføringen.
FoxIDs støtter opplasting av interne brukere med kjente passord, med FoxIDs kompatible forhåndsberegnede passordhasher eller uten passord. En hash fra en vilkårlig kildeplattform kan ikke bare betegnes som en FoxIDs hash. Bekreft nøyaktig algoritme, salt og målformat før dere avgjør at en eksportert hash kan brukes på nytt.
Behandle eksport av passord i klartekst som en sikkerhetsbeslutning, ikke som en bekvemmelighet. Begrens tilgang, bruk en kontrollert overføringsvei, hindre at passord havner i logger eller vanlige prosjektfiler, bekreft sletting av midlertidig materiale og dokumenter hvem som godkjente operasjonen. Hvis håndteringen ikke kan forsvares, bør dere velge nettbasert validering eller tilbakestilling i stedet.
Når passordtilbakestilling er sikrere
En tilbakestilling er ikke nødvendigvis et tegn på en mislykket migrering. Det er den ærlige veien når det å beholde det eksisterende passordet vil svekke målet eller avhenge av antakelser teamet ikke kan verifisere.
Foretrekk en kontrollert tilbakestilling når:
- kilden verken kan eksportere en kompatibel representasjon eller validere det gjeldende passordet på nett;
- flytting av passordmateriale vil skape en uakseptabel eksponering eller et kontraktsproblem;
- passordet i kilden er kjent eller mistenkt kompromittert;
- kontoer ikke kan korreleres med stabile kildeidentiteter med tilstrekkelig sikkerhet;
- kilden ikke kan forbli pålitelig i den nødvendige perioden for gradvis migrering og rollback; eller
- bevaring av det gamle passordet vil kreve svakere kontroller i målet.
FoxIDs brukere kan lastes opp uten passord og bli bedt om å angi et ved hjelp av en verifikasjonskode som sendes via e-post eller SMS. Dette er bare sikkert når identifikatoren for kontogjenoppretting tilhører riktig bruker og leveringskanalen oppfyller organisasjonens risikokrav. Test utløpte koder, utilgjengelige innbokser eller telefonnumre, dupliserte identifikatorer, låste kontoer og eskalering til support før en bred utrulling.
Kommuniser årsak og tidspunkt før brukerne møter tilbakestillingen. Hold sikkerhetsbeslutningen adskilt fra supportplanen: Et godt tilbakestillingsdesign kan fortsatt feile driftsmessig hvis gjenopprettingskanalene er utdaterte eller servicedesk ikke kan håndtere den første belastningen.
Krev bevis før cut-over for passord
Test den valgte veien i et separat FoxIDs miljø, og flytt først en kontrollert brukergruppe. En vellykket innlogging er nødvendig, men ikke tilstrekkelig.
| Beslutningsområde | Bevis som kreves før bredere utrulling |
|---|---|
| Identitetsbinding | Stabile kilde-ID-er, testede endringer av identifikatorer og definert håndtering av duplikater eller manglende brukere |
| Passordatferd | Godkjente og avviste passord, løp for utløpt passord, passordendring/tilbakestilling og policyfeil |
| Tilgjengelighet | Overvåking av connector eller validerings-API, timeouts, feilhåndtering og navngitt driftsansvarlig |
| Brukermigrering | Pilotresultater for representative aktive, inaktive, deaktiverte og begrensede kontoer |
| Sikkerhet | Godkjent håndtering av passordmateriale, beskyttede secrets, diagnostisk logging uten passord og gjennomgått datalagring |
| Cut-over | Exit-kriterier per brukergruppe, håndtering av brukere uten lagret målpassord, rollback-trigger og ansvarlig for utfasing av kilden |
Behold kilden til den nødvendige brukergruppen er migrert og rollback-perioden er avsluttet. Ikke deaktiver connectoren bare fordi piloten lyktes. Verifiser målpassordløpet for populasjonen som må fungere etter cut-over, og behold en kontrollert tilbakestillingsvei for resten.
Slik støtter FoxIDs beslutningen
Bruk dokumentasjonen om migrering til å planlegge applikasjoner, brukere, passord, cut-over og rollback samlet. Dokumentasjonen om Directory Connector, External Password API og opplasting av brukere inneholder de nøyaktige implementeringsdetaljene.
Hvis kildens muligheter, brukergrupper eller cut-over-kriterier ennå ikke er tydelige, beskriver FoxIDs Identity Migration hvordan teamet bak plattformen kan hjelpe med å utforme og gjennomføre migreringen.
Konklusjon
Brukere kan bare beholde et eksisterende passord når migreringen bevarer en pålitelig valideringsvei eller etablerer et kompatibelt målpassord på en sikker måte. Directory Connector gir ofte den minst forstyrrende gradvise veien, men holder også kilden i produksjonsløpet for authentication frem til en bevisst cut-over.
Velg tilbakestilling når kompatibilitet, identitetsbinding eller sikker håndtering ikke kan dokumenteres. Riktig passordstrategi er den som gjør den autoritative kilden, feiladferden, brukerbelastningen og exit-kriteriene tydelige før produksjonstrafikken flyttes.