WSO2 heeft onlangs aangekondigd dat er een release van de nieuwe Identity Server 5.9.0 aan zit te komen. Geen zorgen, het is nog steeds het prijswinnende product met dezelfde vertrouwde functionaliteit. Wanneer er een nieuwe versie van WSO2-producten uitkomt, ben ik altijd wat terughoudend om te weten te komen wat er nieuw aan is. In dit geval met de Identity Server zijn de veranderingen minimaal en is de stap van 5.8.0 naar 5.9.0 maar een kleine. Toch zijn er een aantal veranderingen die de moeite waard zijn om op een rijtje te zetten.
Ten eerste is er een nieuwe generatie aan WSO2 producten die op de Carbon 4.5.x versie draait, ook wel bekend onder de naam Minsky. Minsky is in staat om te draaien op Java 11, wat natuurlijk een grote sprong is vanaf de huidige productreeks die op Java 8 draait, een versie van java die toch al wat jaren meegaat. Voor nu kun je nog steeds Java 8 blijven gebruiken, als dat je voorkeur heeft, maar het is fijn om te weten dat je over kunt stappen wanneer je eraan toe bent.
We hebben nu drie grote WSO2 Carbon platformen, Wilkens (4.4.x), Hamming (5.2.x) en Minsky (4.5.x). Als je je afvraagt waar de namen van de platformen vandaan komen? Het zijn allemaal Winnaars van de Turing Award tussen 1967 en 1969. Wilkinson zal de naam worden van de volgende versie van het platform, als WSO2 dezelfde reeks blijft volgen.
Een nieuw configuratiemodel
Er is een nieuw configuratiemodel in Carbon 4.5 en dat is goed nieuws. Wie van jullie al bekend is met de WSO2-producten, zal weten dat er meerdere configuratiebestanden in de [IS_HOME]/repository/conf map staan.
Er is het axis2-bestand, carbon.xml, master-data sources.xml enzovoorts. In de Identity Server 5.9.0 hebben we nu één master configuratiebestand om ze allemaal mee te managen. De oude XML-bestanden zijn er nog steeds, maar de deployment.toml is een globaal bestand waarin de meeste configuraties voor het product opgenomen zijn. Om het met de woorden van WSO2 te zeggen: “Gebruikers zullen alleen de verplichte en essentiële configuraties die in het product zitten te zien krijgen.’’ En dat is een grote verbetering, omdat iedereen die ooit met de configuraties bezig is geweest, weet hoeveel haken en ogen eraan zitten. Het grote aantal configuratiebestanden, de talloze opties om in te stellen en dat op verschillende locaties zijn enkele van de bekende struikelblokken. Dat zorgt er vervolgens ook voor dat de tijd voor een deployment oploopt, omdat de configuratie maken teruggrijpen op veel bestanden betekent.
Zelfs het onderhouden van een Ansible script houdt in dat je alle XML-bestanden zult moeten identificeren en verwerken om bij te houden waar je de configuratieveranderingen wilt doorvoeren. De deployment.toml, zoals het nieuwe bestand nu genoemd wordt, is het enige bestand dat nu nog veranderd hoeft te worden en dat zal de veranderingen doorzetten naar de XML-bestanden. Je kunt de oude XML-bestanden nog steeds gebruiken als je dat wilt, dus investeringen in Ansible playbooks gaan niet compleet verloren door deze nieuwe functionaliteit. Hiervoor kun je gewoon het deployment.toml bestand verwijderen om terug te schakelen naar de oude configuratie op basis van xml-bestanden.
Cross protocol logout
Eén van de grootste veranderingen is dat we nu een enkele logout kunnen doen over verschillende protocollen. Dat omvat: SAML, Open ID Connect, etcetera (zoals te zien is in de afbeelding hieronder). Hierdoor is een single log out over verschillende protocollen mogelijk, maar er zit één kanttekening aan: in relatie met SAML-applicatie wordt cross protocol logout alleen ondersteund voor SAML-applicaties die back channel logout gebruiken (bijvoorbeeld: synchroon). Front channel wordt door de user-agent geregeld met doorverwijzingen en vereist geen verbindingen tussen IDP en SP. Back channel wordt geregeld tussen componenten zoals IDP en SP. Eén van de redenen om back channel te gebruiken is de controle die het geeft. Wanneer er een token wordt afgewezen, behoudt de ontwikkelaar de volledige controle over een nette afhandeling van de sessie.
Meer API’s
Iets anders wat nieuw is, is het aantal Identity API’s dat nu gebruikt kan worden met betrekking tot de Identity Server en user self-service. Dit is uiteraard heel belangrijk voor CIAM use cases en in het algemeen als je identityfuncties in je app wil embedden. We kennen enkele van deze Identity API’s al uit eerdere versies, zoals de SCIM2 API of de admin service equivalent daarvan. Er is nu de mogelijkheid om alle onderstaande soorten API’s te gebruiken:
- Account Recovery REST API’s
- Self Sign-Up REST API’s
- Authentication REST API’s
- Consent Management REST API’s
- Personal Information Export REST API’s
- Configuration Management REST API’s
- SCIM 2.0 REST API’s
- OpenID Connect Dynamic Client Registration REST API’s
- OAuth2 Scopes REST API’s
- Authenticating en Authorizing REST API’s
- Authentication Data REST API’s
Sub theme capabilities
Met deze versie van de Identity Server kunnen we nu een aantal van de veelgebruikte pagina’s aanpassen met een sub theme. Dit betekent dat we niet opnieuw een hele nieuwe theme gaan definiëren, maar eigenlijk de veranderingen aangeven in het sub thema. Dit is een functie die we ook terugzien in de WSO2 API Manager, waar het theme en subtheme ook de voor de Jaggery apps, zoals de Publisher en de Store ondersteund worden. Ondersteunde pagina’s zijn bijvoorbeeld de sign-up en recovery pagina’s.
Uitgebreidere ondersteuning voor Log4j
De beroemde Log4j properties zijn veranderd in de nieuwe versie van de Identity Server samen met de Management UI mogelijkheid om ze aan te passen. De reden hiervoor is dat er vanaf Kernel 4.5.x geen gebruik meer wordt gemaakt van de carbon.logging jar en er overgestapt is naar de pax-logging-api. Met deze upgrade is ook de Log4j-versie geupdate naar Log4j2. Veranderingen zullen doorgevoerd moeten worden in het Log4j2 properties bestand. Een kanttekening daarbij: de IS 5.9.0 heeft nu een correlation ID die is toegevoegd aan alle plekken waar de logs afgedrukt worden. Deze correlation ID wordt gebruikt om de method calls die voor een enkele request gedaan worden te correleren en wordt na de timestamp afgedrukt.
Migratie
De overgang van de ene versie van een WSO2-product naar een andere vraagt meestal om een migratieproces. In dit geval kun je voor de Identity Server 5.9.0 online de migration pages erop naslaan om te zien wat er gedaan moet worden om over te kunnen stappen naar de nieuwe versie. Alle custom OSGI bundels moeten bijvoorbeeld gerecompiled worden vanwege de veranderingen aan de Carbon Kernel die we nu gebruiken.
Routekaart
Routekaarten voor WSO2-producten zijn nu publiek beschikbaar en dienen als gids voor toekomstige releases, met natuurlijk een disclaimer dat ze alleen voor gedeeld worden voor INFORMATIEVE doeleinden. Hier kun je de nieuwe WSO2 Identity Server roadmap terugvinden. Er is geen indicatie van een tijdsbestek, bijvoorbeeld het 2e kwartaal of 20xx, waarin ieder van deze scenario’s zich zou kunnen voordoen. Maar het blijft goed om te weten wat er gepland staat. Nog een waardevolle informatiebron is de GitHub, waar we kunnen zien dat er gewerkt wordt aan versie 5.10.0-m3 en versie 6.0.0-m2. De broncode kan gedownload en bekeken worden om te zien waar WSO2 op dit moment aan werkt.
Conclusie
De nieuwe versie van de WSO2 Identity Server biedt verbeteringen ten opzichte van de vorige versie, omdat het verder bouwt op de bestaande mogelijkheden. Blijft staan dat het implementeren of updaten van de WSO2 Identity Server geen triviale taak is. Maar we zouden je willen aanraden om deze nieuwe versie te overwegen (inclusief de gefixte en openstaande aandachtspunten en problemen) om te zien of het voor jou waarde kan toevoegen. Als je nog niet met de recentste versie werkt, dan is het verstandig ook de voordelen van eerdere upgrades mee te wegen.
Misschien wacht je op een goede mogelijkheid om de stap naar containers te maken en is deze nieuwe release de aanzet om de sprong te wagen. Het kan sowieso nooit kwaad om een nieuwe release eens uit te testen. En als je dat zou willen, dan helpen we je natuurlijk graag met jouw implementatieplan.
