En passwordmigration er ikke en databasekopi. Når brugere flyttes mellem identity providers, kan kilden ofte ikke levere et password, som målsystemet kan genbruge. Selv hvis en eksport indeholder passwordhashes, er et hashformat fra én platform ikke automatisk gyldigt på en anden.
Brugerne kan i nogle tilfælde beholde deres nuværende password uden et tvunget reset. Den sikre metode afhænger af, hvad kilden kan eksportere, om den kan validere passwords online, hvor længe den kan forblive tilgængelig, og om migrationen kan knytte hver konto til en stabil identifikator fra kilden.
Artiklen giver en beslutningsmodel til at vælge mellem kompatibel import, gradvis passwordvalidering, fortsat ekstern validering og et kontrolleret passwordreset. Fokus er passwordforløbet. Applikationsprotokoller, claims, registrering af multi-factor authentication (MFA) og den samlede cut-over plan skal stadig håndteres som sammenhængende migrationsspor.
Start med kildens muligheder, ikke den ønskede brugeroplevelse
“Intet passwordreset” er et ønskeligt resultat, men endnu ikke en migrationsmetode. Før I vælger en løsning, skal I fastslå, hvad kilden faktisk understøtter:
- Kan den eksportere passwords i klartekst eller en passwordrepræsentation, som målsystemet udtrykkeligt understøtter?
- Kan den validere brugerens nuværende password gennem et beskyttet validerings-API?
- Kan dette API forblive tilgængeligt, overvåget og supporteret gennem en gradvis migration og rollbackperiode?
- Findes der et stabilt og uforanderligt bruger-ID fra kilden, som kan binde den samme konto sammen på tværs af ændringer i loginidentifikatorer?
- Kan passwordændringer og resets holdes konsistente, mens to systemer er involveret?
- Tillader sikkerhedspolitik, kontrakter og risikovurdering, at passwordmateriale importeres eller bevares?
Brug ikke e-mailadresse, telefonnummer eller brugernavn som eneste migrationsnøgle. De identifikatorer kan ændre sig. En forkert kontomatch er mere alvorlig end et reset, fordi loginoplysninger og adgang kan blive knyttet til den forkerte identitet.
Vælg mellem fire passwordforløb
Forskellige brugergrupper kan kræve forskellige forløb. Aktive medarbejdere kan for eksempel migreres gradvist gennem onlinevalidering, mens inaktive eksterne konti får et reset, når de vender tilbage.
| Kildens mulighed og begrænsning | Forsvarligt forløb | Primær fordel | Primær omkostning eller risiko |
|---|---|---|---|
| Passwords eller en passwordrepræsentation, der er kompatibel med målsystemet, er tilgængelige og kan håndteres sikkert | Kontrolleret batchimport | Brugerne kan autentificere direkte i målsystemet | Eksport, transport og behandling af passwordmateriale udvider sikkerhedsgrænsen |
| Kilden kan validere eksisterende passwords online og forblive autoritativ i overgangsperioden | Gradvis migration med Directory Connector | Aktive brugere flyttes ved et vellykket login uden et samlet reset | Kilden og connectoren forbliver i produktionsflowet for authentication indtil cut-over |
| Brugerne er allerede oprettet i FoxIDs, og kun passwordvalidering, policykontrol eller besked om ændringer fortsat er ekstern | External Password API | Bevarer en smallere integration til passwordlager eller passwordpolicy | Giver ikke samme forløb til brugeroprettelse og profilsynkronisering som Directory Connector |
| Der findes hverken sikker kompatibel import eller pålidelig onlinevalidering | Verificeret passwordreset | Etablerer et nyt password i målsystemet med en tydelig trust-grænse | Brugerkommunikation, gendannelseskanaler og supportkapacitet bliver afgørende |
Svaret er derfor ikke altid “bevar” eller altid “reset”. Vælg det mindst forstyrrende forløb, som fortsat kan forsvares teknisk og driftsmæssigt for hver brugergruppe.
Gradvis migration med Directory Connector
Directory Connector er det centrale FoxIDs mønster, når et eksisterende directory eller et specialbygget repository skal forblive autoritativt i overgangsperioden.
Når en bruger logger ind med password, kalder FoxIDs connector API'et. Efter en vellykket validering opretter eller opdaterer FoxIDs den interne bruger ud fra de returnerede identifikatorer, properties og claims. Svaret indeholder et stabilt directoryUserId, som binder brugeren i FoxIDs til kildekontoen, selv hvis brugerens e-mailadresse, telefonnummer eller brugernavn senere ændres.
Det skaber et praktisk just-in-time forløb:
- Brugeren logger ind i en applikation gennem FoxIDs med sin nuværende identifikator og sit password.
- FoxIDs beder kildens directory om at validere passwordet.
- Connectoren returnerer det stabile kilde-ID og de godkendte brugerdata.
- FoxIDs opretter eller opdaterer den interne bruger og gennemfører authentication.
- Brugeren kan fortsætte med det eksisterende password, mens kilden er autoritativ.
Som standard gemmer FoxIDs også en lokal passwordkopi efter en vellykket validering eller password lifecycle handling gennem connectoren. Kopien giver mulighed for senere at skifte planlagt til passwordvalidering i FoxIDs uden at nulstille passwordet for alle de brugere, der har gennemført det gradvise forløb.
Sikkerhedsgrænsen er vigtig: Mens Directory Connector er aktiveret, er det eksterne directory autoritativt. FoxIDs bruger ikke det gemte lokale hash som automatisk fallback, hvis connectoren er utilgængelig. Et nedbrud i connectoren er derfor en fejl i loginforløbet, ikke en instruktion om at omgå kilden.
Indstillingen for passwordpolicy på skærmbilledet er en tredje, selvstændig beslutning. Den afgør, om FoxIDs kontrollerer et foreslået password mod miljøets FoxIDs policy, før connectoren kaldes. Det eksterne directory ejer fortsat passwordet og kan afvise det efter sin egen policy. Hvis begge kontroller bruges, skal krav og brugervejledning afstemmes.
Definér exit-kriterier, før connectoren aktiveres
En gradvis migration skal have en slutbetingelse. Beslut før udrulningen:
- Hvilke brugergrupper skal have gennemført et vellykket login før cut-over?
- Hvordan skal inaktive brugere og brugere, der aldrig vender tilbage, håndteres?
- Hvor længe skal kilden og connectoren være tilgængelige for rollback?
- Hvilke værdier for svartid og fejlrate i connectoren skal standse eller rulle udrulningen tilbage?
- Hvordan undersøges konflikter i identifikatorer, manglende claims samt deaktiverede eller slettede kildekonti?
- Hvornår kan connectoren deaktiveres, så FoxIDs bliver autoritativ for passwords?
Den lokale kopi er valgfri. Deaktivér den, hvis en policy kræver, at kilden forbliver det eneste passwordlager, men vær opmærksom på, at denne vej til et senere skift uden reset dermed fjernes.
Hvornår External Password API er den smallere løsning
FoxIDs kan konfigurere et External Password API som password check for interne brugere. Det kan validere et nuværende password, validere et nyt password mod en ekstern policy, give et andet system besked om passwordændringer eller kombinere disse ansvarsområder.
Brug denne mulighed, når brugerne allerede findes i FoxIDs, og det resterende behov specifikt vedrører passwordlager eller passwordpolicy. Betragt det ikke som en erstatning for Directory Connector, hvis migrationen også kræver just-in-time brugeroprettelse, en stabil binding til et eksternt directory, profilopdateringer eller håndtering af eksterne kontis livscyklus.
Forskellen holder integrationsgrænsen tydelig: Directory Connector repræsenterer et autoritativt eksternt directory. External Password API repræsenterer en ekstern afhængighed til passwordvalidering, policy eller beskeder for interne brugere.
Hvornår batchimport kan forsvares
Batchimport kan fjerne den driftsmæssige afhængighed af kilden, men kun når inputtet er egnet til målsystemet og kan beskyttes gennem hele overførslen.
FoxIDs understøtter upload af interne brugere med kendte passwords, med FoxIDs kompatible forudberegnede passwordhashes eller uden passwords. Et hash fra en vilkårlig kildeplatform kan ikke blot betegnes som et FoxIDs hash. Bekræft den præcise algoritme, salt og målformat, før I konkluderer, at et eksporteret hash kan genbruges.
Behandl eksport af passwords i klartekst som en sikkerhedsbeslutning og ikke som en bekvemmelighed. Begræns adgang, brug en kontrolleret overførselsvej, undgå passwords i logs og almindelige projektfiler, verificér sletning af midlertidigt materiale, og dokumentér hvem der har godkendt handlingen. Hvis håndteringen ikke kan forsvares, skal I i stedet vælge onlinevalidering eller reset.
Hvornår passwordreset er sikrere
Et reset er ikke nødvendigvis tegn på en fejlslagen migration. Det er den ærlige løsning, når bevarelse af det eksisterende password vil svække målsystemet eller afhænge af antagelser, som teamet ikke kan verificere.
Foretræk et kontrolleret reset, når:
- kilden hverken kan eksportere en kompatibel repræsentation eller validere det nuværende password online;
- flytning af passwordmateriale vil skabe en uacceptabel eksponering eller et kontraktmæssigt problem;
- passwordet i kilden er kendt eller mistænkt kompromitteret;
- konti ikke kan korreleres med stabile kildeidentiteter med tilstrækkelig sikkerhed;
- kilden ikke kan være pålidelig i den nødvendige periode til gradvis migration og rollback; eller
- bevarelse af det gamle password kræver svagere kontroller i målsystemet.
FoxIDs brugere kan uploades uden passwords og blive bedt om at angive et ved hjælp af en verifikationskode sendt via e-mail eller SMS. Det er kun sikkert, når identifikatoren til gendannelse tilhører den tilsigtede bruger, og leveringskanalen opfylder organisationens risikokrav. Test udløbne koder, utilgængelige indbakker eller telefonnumre, dublerede identifikatorer, låste konti og eskalering til support før en bred udrulning.
Kommunikér årsag og tidspunkt, før brugerne møder et reset. Hold sikkerhedsbeslutningen adskilt fra supportplanen: Et sundt resetdesign kan stadig fejle driftsmæssigt, hvis gendannelseskanalerne er forældede, eller helpdesk ikke kan håndtere den indledende belastning.
Kræv evidens før password cut-over
Test det valgte forløb i et separat FoxIDs miljø, og flyt først en kontrolleret brugergruppe. Et vellykket login er nødvendigt, men ikke tilstrækkeligt.
| Beslutningsområde | Nødvendig evidens før bredere udrulning |
|---|---|
| Identitetsbinding | Stabile kilde-ID'er, testede ændringer af identifikatorer og defineret håndtering af dubletter eller manglende brugere |
| Passwordadfærd | Accepterede og afviste passwords, forløb for udløbet password, passwordændring/reset og policyfejl |
| Tilgængelighed | Overvågning af connector eller validerings-API, timeouts, fejlhåndtering og navngiven driftsansvarlig |
| Brugermigration | Pilotresultater for repræsentative aktive, inaktive, deaktiverede og begrænsede konti |
| Sikkerhed | Godkendt håndtering af passwordmateriale, beskyttede secrets, diagnostisk logging uden passwords og gennemgået dataopbevaring |
| Cut-over | Exit-kriterier pr. brugergruppe, håndtering af brugere uden et gemt password i målsystemet, rollback trigger og ansvarlig for udfasning af kilden |
Behold kilden, indtil den nødvendige brugergruppe er migreret, og rollbackperioden er afsluttet. Deaktivér ikke connectoren alene, fordi piloten lykkedes. Verificér passwordforløbet i målsystemet for den population, der skal fungere efter cut-over, og bevar en kontrolleret resetvej for resten.
Sådan understøtter FoxIDs beslutningen
Brug dokumentationen om migration til at planlægge applikationer, brugere, passwords, cut-over og rollback samlet. Dokumentationen om Directory Connector, External Password API og upload af brugere beskriver de præcise implementeringsdetaljer.
Hvis kildens muligheder, brugergrupperne eller cut-over kriterierne endnu ikke er tydelige, beskriver FoxIDs Identity Migration, hvordan teamet bag platformen kan hjælpe med at designe og gennemføre migrationen.
Konklusion
Brugere kan kun beholde deres eksisterende password, når migrationen bevarer en troværdig valideringsvej eller etablerer et kompatibelt password sikkert i målsystemet. Directory Connector giver ofte den mindst forstyrrende gradvise vej, men den holder også kilden i produktionsflowet for authentication frem til en bevidst cut-over.
Vælg reset, når kompatibilitet, identitetsbinding eller sikker håndtering ikke kan dokumenteres. Den rigtige passwordstrategi er den, der gør den autoritative kilde, fejladfærd, brugerbelastning og exit-kriterier tydelige, før produktionstrafikken flyttes.