Omgaan met legacy en softwarekwaliteit

Het legacy Entree Federatie-platform op basis van Asimba is geïmplementeerd in drie onderdelen/applicatie-groepen: Asimba, Federatie Authenticatie en Federatie Applicatie.

Asimba betreft een flexibele en modulaire Access Management en Single Sign-On-oplossing en is een voortzetting van het open-source OpenASelect-project, dat ooit ook aan de basis stond van DigiD. Asimba kenmerkt zich als een framework waarop authenticatiefuncties flexibel geïmplementeerd kunnen worden. Ook is het geschreven als J2EE-framework en kan het als middleware eenvoudig aan een eigen architectuur worden toegevoegd.

Federatie Authenticatie is gebaseerd op het Java Spring-framework. Het is gebouwd rondom het Asimba-framework en is verantwoordelijk voor het authenticeren van de gebruikers. Naast Asimba bevat het ook een attributenservice die, op basis van configuratie, ervoor zorgt dat na een succesvolle authenticatie alleen toegestane gebruikersattributen worden gedeeld. Zodoende wordt alleen noodzakelijke informatie naar de dienstleverancier gestuurd.

Federatie Applicatie betreft een bundeling van managementapplicaties die, net als Federatie Authenticatie, zijn gebaseerd op het Java Spring-framework. Het betreft onder andere de administratieschermen voor de interne beheerders van Entree Federatie (de servicedesk van Stichting Kennisnet) en een managementapplicatie voor school- en dienstbeheerders. Hier kunnen dienstleveranciers, Identity Providers en scholen worden geregistreerd, geconfigureerd en verwijderd.

Het platform op basis van Asimba heeft jarenlang bewezen dat het de benodigde en verwachte groei van de capaciteit makkelijk aankan. Waarom is het dan toch noodzakelijk om dit platform te vervangen?

De belangrijkste redenen hiervoor zijn het kunnen meegaan met nieuwe ontwikkelingen en technologieën, en het kunnen doorvoeren van noodzakelijke beveiligingsupdates. Denk daarbij aan de onderliggende Asimba library en andere externe libraries. Vanwege de versies van bepaalde libraries en de afhankelijkheden ervan voor de werking van het platform, kost het relatief veel inspanning om thans bepaalde (noodzakelijke) upgrades door te voeren in Federatie Authenticatie.

Een goed voorbeeld is de Java-implementatie van het SAML-protocol (OpenSAML); een verouderde versie van deze library is diep geïntegreerd in de werking van Asimba. Inmiddels is een nieuwere, volledig herziene versie beschikbaar en is het zeer wenselijk om hier gebruik van te gaan maken. Het upgraden naar deze versie is echter een enorme investering gezien de complexiteit van de implementatie.

Een andere belangrijke reden voor het vervangen van het platform is de beschikbare kennis en ervaring en capaciteit die nodig zijn om het platform te blijven onderhouden en doorontwikkelen. Het Asimba-platform kent sinds 2015 geen actieve community meer, waardoor alle verantwoordelijkheid voor het onderhoud en de doorontwikkeling van het platform bij de gebruiker is komen te liggen, in dit geval Stichting Kennisnet. Vanwege de beperkte grootte van het ontwikkelteam is het moeilijk om tijd en inzet vrij te maken voor innovatie van het platform, terwijl afnemers van Entree Federatie wel nieuwe features, zoals ondersteuning voor protocollen als OpenID Connect, wensen. 

Het Asimba-platform dient te worden vervangen. Een dergelijk traject kent een lange doorlooptijd (op dit onderwerp zal in latere blogs dieper worden ingegaan). Dit betekent dat naast het opbouwen van een nieuw platform, het huidige platform veilig en beheersbaar in de lucht dient te worden gehouden.

Voor een verzameling applicaties zo groot en verbonden als binnen het Entree Federatie-platform is het geen triviale taak om alle applicaties bij te houden. Er zijn dan ook door het ontwikkelteam meerdere maatregelen genomen die in combinatie met een aantal tools zorg dragen voor de beheersbaarheid van alle applicaties en een strategie vormen om in control te blijven.

De eerste verdedigingslinie wordt gevormd door de leden van het team zelf. Deze houden zich aan meerdere maatregelen: zo wordt (defensief) geschreven code altijd door een andere ontwikkelaar geverifieerd en worden de gerealiseerde en/of aangepaste functionaliteiten altijd door een tester getoetst. Ook hanteren zij de regel dat automatische testen worden geschreven voor elke codewijziging. Om teamleden te helpen deze maatregelen te handhaven en om menselijke fouten te beperken, worden ondersteunende tools gebruikt.

SonarQube, een code review tool, wordt door het team primair ingezet om codekwaliteit te borgen. Bij elke wijziging in de code wordt automatisch een scan van de gehele codebase uitgevoerd. SonarQube ondersteunt door het makkelijk vindbaar maken van bestaande programmeerfouten, maar ook van code die later voor problemen kan zorgen. Een voorbeeld hiervan is het gebruiken van dezelfde code op meerdere plekken (codeduplicatie). Dit kan foutgevoelig blijken omdat zo de kans ontstaat dat een plek vergeten wordt als in deze code een verbetering moet worden doorgevoerd. Beter zou zijn als deze gemeenschappelijke code in een aparte functie wordt geplaatst die op meerdere plekken kan worden aangeroepen.

Tevens maakt SonarQube inzichtelijk waar er sprake is van complexe code. Door middel van voorgedefiniëerde codeerregels kan SonarQube worden ingezet om complexe code te identificeren. Door deze complexe code te herschrijven, wordt de algehele leesbaarheid ervan verbeterd en kan de kans op mogelijke codefouten en/of security hotspots worden gereduceerd.

SonarQube geeft daarnaast de dekkingsgraad weer over de code heen door geautomatiseerde testen. Deze testen worden ook wel ‘unit tests’ genoemd, omdat elke test een afzonderlijk deel van de code test. SonarQube geeft deze dekkingsgraad als percentage weer en betreft het aantal automatisch geteste coderegels ten opzichte van het totaalaantal testbare coderegels. De gehanteerde maatregel is dat dit percentage niet onder de 80% mag vallen. Wanneer een codewijziging ervoor zorgt dat dit wel het geval is, wordt er gekeken welke delen van die code nog niet getest worden en hoe dit wel kan gebeuren. Daarbij is het ook de regel om voor elke codewijziging direct een unit test te schrijven, zodat het effect van de wijziging in enige mate constant blijft, zelfs na toekomstige wijzigingen.

Asimba maakt ook gebruik van code van allerlei externe partijen. Hoewel dit normaal is voor dergelijke libraries, brengt het wel risico’s met zich mee, zeker wanneer een library een seniore leeftijd bereikt en beperkt onderhoud en beperkte doorontwikkeling kent. Externe code kan namelijk veiligheidsproblemen bevatten waardoor het platform dat gebruikmaakt van deze externe code zelf mogelijk kwetsbaar wordt. Om op de hoogte te blijven van bekende veiligheidsrisico’s, wordt ook hier een automatische scan gebruikt. Zodra in een externe library een kwetsbaarheid wordt ontdekt, wordt er automatisch een e-mail gestuurd naar het team dat vervolgens informatie ontvangt over de oorzaak, eventuele oplossingen en de grootte van het risico. Dankzij de agile manier van werken, kan hier daadkrachtig op worden geprioriteerd en snel aan het veiligheidsrisico worden gewerkt om nadelige neveneffecten te minimaliseren.