Een wachtwoordmigratie is geen databasekopie. Wanneer gebruikers tussen identity providers worden verplaatst, kan de bron vaak geen wachtwoord leveren dat het doel opnieuw kan gebruiken. Zelfs als een export wachtwoordhashes bevat, is een hash die voor het ene platform is gemaakt niet automatisch geldig op een ander platform.
Gebruikers kunnen soms hun bestaande wachtwoord behouden zonder een verplichte reset. De veilige methode hangt af van wat de bron kan exporteren, of deze wachtwoorden online kan valideren, hoelang de bron beschikbaar kan blijven en of de migratie ieder account aan een stabiele bron-ID kan koppelen.
Dit artikel biedt een beslismodel voor de keuze tussen compatibele import, geleidelijke wachtwoordvalidatie, voortgezette externe validatie en een gecontroleerde wachtwoordreset. Het richt zich op het wachtwoordpad. Applicatieprotocollen, claims, registratie voor multi-factor authentication (MFA) en het volledige cut-over-plan moeten nog steeds als samenhangende migratiesporen worden behandeld.
Begin bij de bron, niet bij de gewenste gebruikerservaring
‘Geen wachtwoordreset’ is een gewenst resultaat, maar nog geen migratiemethode. Stel voordat u een aanpak kiest vast wat de bron werkelijk ondersteunt:
- Kan de bron wachtwoorden in leesbare tekst exporteren of een wachtwoordrepresentatie die het doel expliciet ondersteunt?
- Kan de bron het huidige wachtwoord van een gebruiker via een beveiligde validatie-API controleren?
- Kan deze API tijdens een geleidelijke migratie en het rollback-venster beschikbaar, bewaakt en ondersteund blijven?
- Is er een stabiele, onveranderlijke bron-ID voor de gebruiker waarmee hetzelfde account bij gewijzigde identifiers gekoppeld blijft?
- Kunnen wachtwoordwijzigingen en resets consistent blijven zolang twee systemen betrokken zijn?
- Staan beveiligingsbeleid, contracten en risicobeoordeling toe dat wachtwoordmateriaal wordt geïmporteerd of bewaard?
Gebruik een e-mailadres, telefoonnummer of gebruikersnaam niet als enige migratiesleutel. Deze identifiers kunnen veranderen. Een onjuiste accountkoppeling is ernstiger dan een reset, omdat aanmeldgegevens en toegang dan aan de verkeerde identiteit kunnen worden gekoppeld.
Kies een van vier wachtwoordpaden
Verschillende gebruikersgroepen kunnen verschillende paden nodig hebben. Actieve medewerkers kunnen bijvoorbeeld geleidelijk via onlinevalidatie migreren, terwijl slapende externe accounts bij terugkeer een reset krijgen.
| Mogelijkheid en beperking van de bron | Verdedigbaar pad | Belangrijkste voordeel | Belangrijkste kosten of risico |
|---|---|---|---|
| Wachtwoorden of een doelcompatibele wachtwoordrepresentatie zijn beschikbaar en kunnen veilig worden verwerkt | Gecontroleerde batchimport | Gebruikers kunnen zich direct bij het doel authenticeren | Export, overdracht en verwerking van wachtwoordmateriaal vergroten de beveiligingsgrens |
| De bron kan bestaande wachtwoorden online valideren en tijdens de overgang autoritatief blijven | Geleidelijke migratie met Directory Connector | Actieve gebruikers migreren bij een geslaagde aanmelding zonder algemene reset | De bron en connector blijven tot de cut-over onderdeel van het productiepad voor authentication |
| Gebruikers zijn al in FoxIDs ingericht en alleen wachtwoordvalidatie, beleidscontrole of wijzigingsmelding blijft extern | External Password API | Behoudt een smallere integratie met de wachtwoordopslag of het beleid | Biedt niet hetzelfde proces voor gebruikerscreatie en profielsynchronisatie als Directory Connector |
| Er bestaat geen veilige compatibele import of betrouwbare onlinevalidatie | Geverifieerde wachtwoordreset | Stelt een nieuw doelwachtwoord vast met een duidelijke trustgrens | Gebruikerscommunicatie, herstelkanalen en supportcapaciteit worden cruciaal |
Het antwoord is dus niet altijd ‘behouden’ of altijd ‘resetten’. Kies voor iedere gebruikersgroep het minst verstorende pad dat technisch en operationeel nog kan worden verdedigd.
Geleidelijke migratie met Directory Connector
Directory Connector is het belangrijkste FoxIDs patroon wanneer een bestaande directory of aangepaste repository tijdens de overgang autoritatief moet blijven.
Wanneer een gebruiker zich met een wachtwoord aanmeldt, roept FoxIDs de connector-API aan. Na succesvolle validatie maakt of actualiseert FoxIDs de interne gebruiker op basis van de teruggegeven identifiers, eigenschappen en claims. Het antwoord bevat een stabiele directoryUserId die de gebruiker in FoxIDs aan het bronaccount koppelt, ook als het e-mailadres, telefoonnummer of de gebruikersnaam later verandert.
Dit levert een praktisch just-in-time-proces op:
- De gebruiker meldt zich via FoxIDs bij een applicatie aan met de bestaande identifier en het wachtwoord.
- FoxIDs laat de bron-directory het wachtwoord valideren.
- De connector geeft de stabiele bron-ID en goedgekeurde gebruikersgegevens terug.
- FoxIDs maakt of actualiseert de interne gebruiker en voltooit de authentication.
- De gebruiker kan het bestaande wachtwoord blijven gebruiken zolang de bron autoritatief blijft.
Standaard slaat FoxIDs ook een lokale wachtwoordkopie op na succesvolle connectorvalidatie of een wachtwoordlevenscyclusactie via de connector. Die kopie maakt een latere geplande overstap naar wachtwoordvalidatie in FoxIDs mogelijk zonder het wachtwoord te resetten van iedere gebruiker die het geleidelijke proces heeft voltooid.
De grens is belangrijk: zolang Directory Connector is ingeschakeld, blijft de externe directory autoritatief. FoxIDs gebruikt de opgeslagen lokale hash niet als automatische fallback wanneer de connector niet beschikbaar is. Een connectorstoring is daarom een fout in het authentication-pad, geen instructie om de bron te omzeilen.
De hieronder getoonde schakelaar voor wachtwoordbeleid is een derde, onafhankelijke beslissing. Deze bepaalt of FoxIDs een voorgesteld wachtwoord aan het beleid van de FoxIDs omgeving toetst voordat de connector wordt aangeroepen. De externe directory blijft eigenaar van het wachtwoord en kan het volgens het eigen beleid afwijzen. Als beide controles worden gebruikt, moeten vereisten en gebruikersinstructies op elkaar aansluiten.
Definieer exitcriteria voordat u de connector inschakelt
Een geleidelijke migratie heeft een eindvoorwaarde nodig. Beslis vóór de uitrol:
- Welke gebruikersgroepen moeten vóór de cut-over een geslaagde aanmelding hebben voltooid?
- Hoe worden inactieve accounts of accounts van gebruikers die nooit terugkeren behandeld?
- Hoelang moeten de bron en connector beschikbaar blijven voor rollback?
- Bij welke responstijden en foutpercentages van de connector wordt de uitrol gestopt of teruggedraaid?
- Hoe worden conflicten tussen identifiers, ontbrekende claims en uitgeschakelde of verwijderde bronaccounts onderzocht?
- Wanneer kan de connector worden uitgeschakeld en kan FoxIDs autoritatief worden voor wachtwoorden?
Het opslaan van een lokale kopie is optioneel. Schakel dit uit wanneer beleid vereist dat de bron de enige wachtwoordopslag blijft, maar besef dat dit het pad naar een latere overstap zonder reset verwijdert.
Wanneer External Password API de smallere oplossing is
FoxIDs kan een External Password API configureren als wachtwoordcontrole voor interne gebruikers. Deze kan een huidig wachtwoord valideren, een nieuw wachtwoord aan extern beleid toetsen, een ander systeem over wachtwoordwijzigingen informeren of deze verantwoordelijkheden combineren.
Gebruik deze optie wanneer de gebruikers al in FoxIDs bestaan en de resterende behoefte specifiek om de wachtwoordopslag of het wachtwoordbeleid gaat. Behandel dit niet als vervanging voor Directory Connector wanneer de migratie ook just-in-time-gebruikerscreatie, een stabiele koppeling met een externe directory, profielupdates of beheer van de levenscyclus van externe accounts vereist.
Dit onderscheid houdt de integratiegrens expliciet: Directory Connector vertegenwoordigt een autoritatieve externe directory. External Password API vertegenwoordigt een externe afhankelijkheid voor wachtwoordvalidatie, beleid of meldingen voor interne gebruikers.
Wanneer batchimport verdedigbaar is
Batchimport kan de runtime-afhankelijkheid van de bron verwijderen, maar alleen wanneer de invoer geschikt is voor het doel en gedurende de hele overdracht kan worden beschermd.
FoxIDs ondersteunt het uploaden van interne gebruikers met bekende wachtwoorden, met vooraf berekende wachtwoordhashes die compatibel zijn met FoxIDs of zonder wachtwoorden. Een hash van een willekeurig bronplatform kan niet zomaar een FoxIDs hash worden genoemd. Controleer het exacte algoritme, de salt en het doelformaat voordat u besluit dat een geëxporteerde hash herbruikbaar is.
Behandel de export van wachtwoorden in leesbare tekst als een beveiligingsbeslissing, niet als gemak. Beperk toegang, gebruik een gecontroleerd overdrachtspad, voorkom dat wachtwoorden in logs of gewone projectbestanden terechtkomen, verifieer de verwijdering van tijdelijk materiaal en documenteer wie de handeling heeft goedgekeurd. Als die verwerking niet te verdedigen is, kies dan voor onlinevalidatie of reset.
Wanneer een wachtwoordreset veiliger is
Een reset is niet noodzakelijk bewijs van een mislukte migratie. Het is de eerlijke route wanneer behoud van het bestaande wachtwoord het doel zou verzwakken of afhankelijk is van aannames die het team niet kan verifiëren.
Kies bij voorkeur voor een gecontroleerde reset wanneer:
- de bron geen compatibele representatie kan exporteren en het huidige wachtwoord niet online kan valideren;
- het verplaatsen van wachtwoordmateriaal onaanvaardbare blootstelling of een contractueel probleem veroorzaakt;
- het wachtwoord in de bron aantoonbaar of vermoedelijk is gecompromitteerd;
- accounts niet met voldoende zekerheid aan stabiele bronidentiteiten kunnen worden gekoppeld;
- de bron niet betrouwbaar kan blijven gedurende de benodigde periode voor geleidelijke migratie en rollback; of
- behoud van het oude wachtwoord zwakkere controles in het doel vereist.
Gebruikers in FoxIDs kunnen zonder wachtwoord worden geüpload en worden gevraagd er een in te stellen met een verificatiecode per e-mail of SMS. Dit is alleen veilig wanneer de identifier voor accountherstel bij de beoogde gebruiker hoort en het bezorgkanaal aan de risicovereisten van de organisatie voldoet. Test verlopen codes, onbereikbare inboxen of telefoonnummers, dubbele identifiers, vergrendelde accounts en supportescalatie vóór een brede uitrol.
Communiceer reden en timing voordat gebruikers met de reset worden geconfronteerd. Scheid de beveiligingsbeslissing van het supportplan: een degelijk resetontwerp kan operationeel nog steeds mislukken als herstelkanalen verouderd zijn of de servicedesk de eerste belasting niet aankan.
Vereis bewijs vóór de wachtwoord-cut-over
Test het gekozen pad in een afzonderlijke FoxIDs omgeving en migreer eerst een gecontroleerde gebruikersgroep. Een geslaagde aanmelding is noodzakelijk, maar niet voldoende.
| Beslissingsgebied | Vereist bewijs vóór bredere uitrol |
|---|---|
| Identiteitskoppeling | Stabiele bron-ID's, geteste wijzigingen van identifiers en gedefinieerde afhandeling van duplicaten of ontbrekende gebruikers |
| Wachtwoordgedrag | Geaccepteerde en afgewezen wachtwoorden, proces voor verlopen wachtwoorden, wachtwoordwijziging/reset en beleidsfouten |
| Beschikbaarheid | Bewaking van connector of validatie-API, time-outs, foutafhandeling en benoemde operationele eigenaar |
| Gebruikersmigratie | Pilotresultaten voor representatieve actieve, inactieve, uitgeschakelde en beperkte accounts |
| Beveiliging | Goedgekeurde verwerking van wachtwoordmateriaal, beschermde secrets, diagnostische logging zonder wachtwoorden en beoordeelde gegevensbewaring |
| Cut-over | Exitcriteria per gebruikersgroep, behandeling van gebruikers zonder opgeslagen doelwachtwoord, rollback-trigger en eigenaar van de uitfasering van de bron |
Houd de bron beschikbaar totdat de vereiste gebruikersgroep is gemigreerd en het rollback-venster is gesloten. Schakel de connector niet alleen uit omdat de pilot is geslaagd. Verifieer het doelwachtwoordpad voor de groep die na de cut-over moet werken en behoud een gecontroleerd resetpad voor de rest.
Hoe FoxIDs de beslissing ondersteunt
Gebruik de migratiedocumentatie om applicaties, gebruikers, wachtwoorden, cut-over en rollback samen te plannen. De documentatie voor Directory Connector, External Password API en het uploaden van gebruikers bevat de exacte implementatiedetails.
Als de mogelijkheden van de bron, gebruikersgroepen of cut-over-criteria nog niet duidelijk zijn, beschrijft FoxIDs Identity Migration hoe het team achter het platform kan helpen de migratie te ontwerpen en uit te voeren.
Conclusie
Gebruikers kunnen een bestaand wachtwoord alleen behouden wanneer de migratie een betrouwbaar validatiepad behoudt of veilig een compatibel doelwachtwoord vastlegt. Directory Connector biedt vaak het minst verstorende geleidelijke pad, maar houdt de bron ook tot een bewuste cut-over in het productiepad voor authentication.
Kies voor reset wanneer compatibiliteit, identiteitskoppeling of veilige verwerking niet kan worden aangetoond. De juiste wachtwoordstrategie maakt de autoritatieve bron, het foutgedrag, de gebruikersimpact en exitcriteria expliciet voordat productieverkeer wordt verplaatst.