Door: Patrick Bes & Chaim Zonnenberg

De overstap naar een nieuw software landschap
Verouderde software… welke ontwikkelaar heeft er geen ervaring mee? Jarenlang heeft je bedrijf functionaliteit ontwikkeld in dezelfde applicatie.
De oorspronkelijke ontwikkelaars van de applicatie zijn al lang geleden vertrokken. In de loop der tijd is in de code van alles aan elkaar geknoopt.
Het gevolg: het proces neemt vier keer zoveel tijd in beslag , kost steeds meer en levert steeds minder releases op. Een grote legacy applicatie ontstaat, oftewel: een monoliet, een “Big Ball of Mud”.

Tijd voor iets nieuws? Het vervangen van een legacy applicatie is een uitdaging. Het is de trend om een monoliet te vervangen door een microservices landschap in de cloud. Dit biedt voordelen als snel releasen, snelle feedback en makkelijk experimenteren met nieuwe features. Maar hoe migreer je nu zo’n Big Ball of Mud naar een Microservices landschap?

Big-bang migratiestrategie
We horen regelmatig dat een ontwikkelteam het migreren naar een microservice landschap complex vindt. Het omgaan met afhankelijkheden, het overzetten van de aanwezige data en vaak ook de security, maken dit tot een complexe operatie. Daarom kiezen organisaties ervoor om alles in één big bang over te zetten: eerst een compleet nieuw landschap ontwikkelen om veel later – wanneer het nieuw ontwikkelde beter is dan de legacy applicatie – in één keer over te stappen. Aan deze strategie zit een groot nadeel vast: je investeert zonder direct rendement. In de praktijk ben je dan vooral de oude applicatie aan het nabouwen. Doordat er geen productie-feedback is, vindt er nauwelijks echte vernieuwing plaats in je applicatie.

Stap-voor-stap migratie
Toch is het mogelijk om stap-voor-stap over te gaan. Dit vereist een heldere blik op de doelarchitectuur waarbij je voorkomt dat legacy elementen vermengd raken met de nieuwe microservices wereld. Ook is een goed plan nodig waarin pijnpunten en risico’s goed in kaart gebracht zijn. Op het vlak van Security is het belangrijk dat tijdens de migratieperiode een eindgebruiker toegang krijgt zonder onderlinge obstructies tussen de monoliet en de microservices. Door de onderlinge uitwisseling van toegangstokens ondervindt de eindgebruiker geen hinder van het wisselen tussen die twee omgevingen.

In deze blog
Met deze blog geven wij een overzicht van de verschillende opties voor een migratie scenario. Dit is het eerste van drie artikelen waarbij wij inzoomen op de aandachtspunten en implementatie keuzes. In het volgende deel ligt de focus meer op keuzes voor het te gebruiken protocol. We sluiten af met een aantal voorbeeld scenario’s en codevoorbeelden.

Keuzes

SAAS or not to SAAS?
De titel van de blog serie geeft aan dat wij ons focussen op het gebruik van IdentityServer4. Maar waarom kiezen wij niet voor een SaaS oplossing als Auth0, OKTA of Azure AD? Wij hanteren als uitgangspunt de migratie van een monoliet naar een microservices model waarbij beide omgevingen tijdens dit proces naast elkaar beschikbaar blijven. Dit impliceert de uitwisseling van toegangstokens tussen beide omgevingen. Het is in veel gevallen een gegeven dat een legacy applicatie zoals onze monoliet een On-premise datastore gebruikt met hierin de credentials van de gebruikers. Deze zijn vaak niet of moeilijk te verplaatsen naar de datastore van een SaaS oplossing. Wachtwoorden zijn meestal met een hash opgeslagen en hierdoor per definitie niet meer te ontsleutelen. Het migreren van deze credentials naar een SaaS datastore betekent dat alle gebruikers een nieuw wachtwoord krijgen. Dat is niet altijd wenselijk. Daarnaast is het vaak niet toegestaan om gebruikers credentials in de cloud op te slaan door regelgeving. Op basis van deze randvoorwaarden is IdentityServer4 een voor de hand liggende keuze. Vooral omdat IdentityService4 in de basis een set aan opensource nuget libraries biedt en wij hierdoor veel vrijheid op het gebied van implementatie en hosting krijgen.

Rol SSO-microservice
In het vervolg van deze blog gaan we er vanuit dat er in het nieuwe landschap één centrale SSO-microservice is. Deze SSO-microservice geeft tokens uit voor autorisatie op API’s. Daarnaast biedt het de mogelijkheid om in te loggen op je clients. Sterker nog: SSO is één van de randvoorwaarden voor het begin van een microservice architectuur. Een gefaseerde invoering van nieuwe microservices in combinatie met een SSO oplossing verloopt dan als volgt:
1. Zorg voor een centraal component voor authenticatie en autorisatie.
2. Faciliteer het federeren tussen monoliet en SSO microservice.
3. Benut de SSO Microservice als centraal inlogpunt. De monoliet gebruikt deze dan ook.

Claim mapping
Het security model van de monoliet is vaak gebaseerd op oude security principes: bijvoorbeeld names en roles. Een microservice landschap werkt meestal met claims en scopes. Gebruik een Anti-Corruption-Layer (ACL) om de wereld van de monoliet en het microservice landschap gescheiden te houden. Vertaal de credentials van de ene naar de andere wereld via een claim mapping. Voorkom dat details uit het security model van de monoliet zich vermengen met het nieuwe security model. Want als iets eenmaal in het nieuwe security model zit, raakt het niet snel weer kwijt.

Veiligheid voor alles
Hoe blijft het hele applicatielandschap veilig tijdens de migratie? Hou rekening met de volgende zaken:

Voorkom zelfbouw
Custom security code zorgt voor veiligheidslekken, zeker als veel verschillende ontwikkelaars aan de dezelfde broncode werken. De geschiedenis wijst uit dat bestaande monolieten vaak bol staan van custom security code. De introductie van een SSO-microservice biedt een goede gelegenheid om deze code uit te faseren. Introduceer in ieder geval geen nieuwe custom code.

Uitloggen niet vergeten
In het kader “veiligheid voor alles” is uitloggen ook een belangrijk onderwerp. Dit klinkt als een open deur, maar is toch relevant. Het gebruik van standaard protocollen ondersteunt het uitloggen. Hou tijdens de migratie rekening met testscenario’s die uitloggen op alle verschillende onderdelen van het landschap (dus uitloggen op de monoliet en op de microservice). Controleer ook altijd of beide onderdelen zijn uitgelogd.

Standaard security protocollen/specificaties
Kijk bij de ontwikkeling een federatie scenario tussen een legacy monoliet en de nieuwe SSO microservice als eerste welke protocollen en/of specificaties de monoliet ondersteunt. Wellicht is het mogelijk om WS-fed of SAML te gebruiken. Het is dan aan te raden om een keuze te maken voor een degelijke specificatie, boven de introductie van een zelf ontwikkelde uitwisseling van gegevens.

Het vervolg
De volgende stap is de keuze voor het uitwisselingsprotocol tussen de monoliet en de microservices. De mogelijkheden zijn ondermeer OpenID Connect, WSfederation of SAML. In de volgende blog gaan wij hier verder op in.

Auteurs: Patrick Bes & Chaim Zonnenberg, Bergler Competence Center © 2019