Het migreren van identiteitsgegevens van het ene platform naar het andere kan riskant en complex lijken, vooral wanneer er gebruikers, wachtwoorden en applicaties bij betrokken zijn. We hebben een oplossing bedacht die de migratie van Auth0 naar de nieuwste versie van WSO2 Identity Server veilig, herhaalbaar, minimaal verstorend voor gebruikers en flexibel genoeg maakt om meerdere applicaties te ondersteunen.
In dit bericht delen we de algemene strategie die we voor verschillende van onze klanten hebben ontworpen en geïmplementeerd.
1. Migratie van organisaties of tenants vanuit Auth0
In WSO2 Identity Server (IS) helpt de organisatie om applicaties en gebruikers te scheiden. Dit is vergelijkbaar met het hiërarchische organisatiebeheer in Auth0, zodat we organisaties in Auth0 rechtstreeks kunnen migreren naar WSO2 Identity Server-organisaties.
In dit proces hebben we besloten om elke Auth0-organisatie te koppelen aan een organisatie in WSO2 IS. Hierdoor blijven gebruikersopslag, applicatieconfiguraties en authenticatiebeleid geïsoleerd, wat toekomstige schaalvergroting of scheiding veel gemakkelijker maakt.
2. Migratie van apps vanuit Auth0
Voor minder dan 5 applicaties kunnen we handmatig applicaties aanmaken in WSO2 IS met verschillende client-id’s en secrets. Als we exacte client-id’s en secrets uit Auth0 willen migreren, kunnen we onze door Yenlo gemaakte client gebruiken om alle apps uit Auth0 te migreren via een json-export.
3. Migreren van gebruikers uit Auth0
In Auth0 kunnen we gebruikersinformatie op verschillende manieren exporteren:
- Kritieke gegevens zoals wachtwoord-hashes kunnen worden geëxporteerd als json
- Andere gebruikersmetadata kunnen als csv worden geëxporteerd vanuit de Auth0-portal
Deze exports bevatten de essentiële identiteitsattributen die we nodig hebben om accounts opnieuw aan te maken in WSO2 IS. Bij Yenlo hebben we een speciale client voorbereid die deze geëxporteerde json- en csv-bestanden kan gebruiken en dezelfde set gebruikers en wachtwoorden kan genereren in WSO2 IS.
Om de consistentie van de gegevens tijdens de migratie te beheren, hebben we besloten om geen nieuwe aanmeldingen, wachtwoordresets of updates van gebruikersprofielen toe te staan in Auth0 of WSO2
Vervolgens voegen we een nieuwe vlag “isOAuth0User = true” toe als systeemattribuut in WSO2. Hierdoor kunnen we onderscheid maken tussen twee sets gebruikers uit verschillende bronnen. Deze vlag wordt later ook cruciaal voor de authenticatielogica.
Aangezien WSO2 IS momenteel geen bcrypt ondersteunt, worden de gebruikers in eerste instantie aangemaakt met een tijdelijk wachtwoord, omdat WSO2 IS de bcrypt-hash van Auth0 niet rechtstreeks kan opslaan. De echte hash blijft veilig opgeslagen in een tijdelijke tabel.
Zodra alle gebruikers zijn gemigreerd naar WSO2 IS, worden de bcrypt-hashes uit de tijdelijke tabel gekopieerd naar de WSO2 Userstore. Er is geen salt voor de bcrypt-hash, omdat deze intern is gebouwd met een salt.
Op dit moment bestaan zowel gebruikers als Auth0-wachtwoord-hashes in WSO2, maar WSO2 Identity Server moet nog steeds begrijpen hoe ze moeten worden geauthenticeerd
Dit is waar onze andere extensie in beeld komt.
Een aangepaste extensie voor een naadloze eerste login
Om een soepele inlogervaring te bieden, heeft Yenlo een extensie voor de userstore gemaakt die op intelligente wijze omgaat met door Auth0 gemigreerde gebruikers. Hoe dit werkt tijdens het inloggen:
Stap 1 — Controleer de Auth0-vlag
Als isOAuth0User = false → WSO2 gebruikt zijn normale authenticatie. Als isOAuth0User = true → Het systeem weet dat de gebruiker nog steeds een Auth0 bcrypt-hash heeft.
Stap 2 — Valideren met behulp van de Auth0 bcrypt-hash
De aangepaste gebruikersopslag voert een bcrypt-verificatie uit op de gemigreerde bcrypt-hash en controleert of deze correct is gevalideerd.
Stap 3 — Het wachtwoord stilzwijgend upgraden
Het juiste wachtwoord wordt onmiddellijk opnieuw gehasht met behulp van het native hashing-algoritme van WSO2. Het WSO2-record van de gebruiker wordt bijgewerkt met de nieuwe hash en salt.
Stap 4 — Schakel de migratievlag uit
We stellen “https://wso2.org/claims/isOAuth0User = false” in om aan te geven dat de gebruiker volledig is overgestapt en dat toekomstige aanmeldingen de standaard WSO2-authenticatiestroom gebruiken.
Vanuit het perspectief van de gebruiker is dit hele proces onzichtbaar. Ze loggen gewoon één keer in en het systeem doet de rest.
Waarom deze aanpak werkt
✔ Geen downtime – Gebruikers kunnen hun bestaande wachtwoorden blijven gebruiken, behalve bij het opnieuw instellen van wachtwoorden en het aanmaken van nieuwe gebruikers.
✔ Geen gedwongen wachtwoordresets – Een groot voordeel voor de gebruiksvriendelijkheid: geen massale resetcampagnes.
✔ Wachtwoorden blijven veilig – Wachtwoorden in leesbare tekst worden nooit blootgesteld.
✔ Soepel migratietraject – Gebruikers stappen bij hun eerste aanmelding naadloos over op het nieuwe hash-algoritme.
✔ Schaalbaar – Elke applicatie/tenant kan afzonderlijk worden gemigreerd.
Conclusie
Identiteitsmigratie hoeft niet pijnlijk te zijn. Door organisatorische mapping, een gecontroleerd importproces via een dynamische client, tijdelijke opslag voor wachtwoord-hashes en een slimme aangepaste gebruikersopslag-extensie te combineren, konden we gebruikers veilig, soepel en zonder onderbreking van hun ervaring migreren van Auth0 naar WSO2 Identity Server.
Als je een soortgelijke migratie plant of meer technische informatie wilt over een van de componenten, download onze WSO2 integratieoplossingen brochure of neem contact met ons op!
