Vor kurzem hat WSO2 die Veröffentlichung des neuen Identity Server 5.9.0 angekündigt. Keine Angst, es ist immer noch das preisgekrönte Produkt, das die Funktionen unterstützt, mit denen Sie vertraut sind. Wenn es eine neue Version der WSO2-Produkte gibt, bin ich immer sehr gespannt, was es Neues gibt. In diesem Fall mit dem Identity Server sind die Änderungen minimal, von 5.8.0 auf 5.9.0 ist nur ein kleiner Schritt. Dennoch gibt es einige Dinge, die erwähnenswert sind.
Zuerst einmal gehört dies zu einer neuen Generation von WSO2-Produkten, die auf der Version Carbon 4.5.x, auch bekannt als Minsky, laufen. Minsky ist in der Lage, auf Java 11 zu laufen, was natürlich ein großer Sprung gegenüber den aktuellen Produkten ist, die auf Java 8 laufen, einer Version, die bereits mehrere Jahre alt ist. Im Moment können Sie noch Java 8 verwenden, wenn Sie das bevorzugen, aber es ist gut zu wissen, dass Sie migrieren können, wenn Sie dazu bereit sind.
Es gibt jetzt drei große WSO2 Carbon Plattformen: Wilkens (4.4.x), Hamming (5.2.x) und Minsky (4.5.x). Falls Sie sich fragen, wie diese Plattformen benannt wurden? Die Antwort ist, dass sie alle zwischen 1967 und 1969 mit dem Turing Award ausgezeichnet wurden. Wilkinson wird die nächste Plattformversion sein, wenn WSO2 bei dieser Art der Namensgebung bleibt.
Ein neues Konfigurationsmodell
Es gibt ein neues Konfigurationsmodell in Carbon 4.5, und das ist eine gute Nachricht. Wer bereits mit den WSO2 Produkten vertraut ist, weiß, dass es im Verzeichnis [IS_HOME]/repository/conf mehrere Konfigurationsdateien gibt.
Es gibt die Datei axis2, carbon.xml, master-data sources.xml und so weiter. Mit Identity Server 5.9.0 haben wir jetzt eine einzige Master-Konfigurationsdatei, die für alle gilt. Die alten XML-Dateien sind immer noch vorhanden, aber die deployment.toml ist eine globale Datei, die die meisten Konfigurationen für das Produkt enthält. Um WSO2 zu zitieren: „Die Benutzer sehen nur die obligatorischen und wesentlichen Konfigurationen, die im Produkt enthalten sind.“ Das ist eine enorme Verbesserung, denn jeder, der schon einmal Konfigurationen vorgenommen hat, weiß, welche Herausforderungen damit verbunden sind. Die schiere Menge an Konfigurationsdateien, die zahlreichen Konfigurationsoptionen und die unterschiedlichen Speicherorte sind nur einige der Probleme. Das macht auch die Bereitstellung zeitaufwändig, da die Konfiguration viele Dateien berührt.
Selbst wenn Sie ein Ansible-Skript pflegen, müssen Sie alle XML-Dateien, in denen Sie Konfigurationsänderungen vornehmen möchten, identifizieren und einbinden. Die Datei deployment.toml, wie die Datei jetzt heißt, ist die einzige Datei, die geändert werden muss und die die Änderungen an die XML-Dateien weitergibt. Sie können auch weiterhin die alten XML-Dateien verwenden, so dass Ihre Investitionen in Ansible-Playbooks durch diese neue Funktion nicht umsonst sind. Um zur alten xml-basierten Konfiguration zurückzukehren, entfernen Sie einfach die Datei deployment.toml.
Protokollübergreifende Abmeldung
Eine der wichtigsten Änderungen ist, dass wir jetzt eine einzige Abmeldung über mehrere Protokolle hinweg durchführen können. Das heißt, SAML, Open ID Connect usw. (wie in der Abbildung unten gezeigt), so dass Sie sich über mehrere Protokolle hinweg einzeln abmelden können. Es gibt jedoch einen Haken: In Bezug auf SAML-Anwendungen wird die protokollübergreifende Abmeldung nur für SAML-Anwendungen unterstützt, die die Abmeldung über den Rückkanal (z.B. synchron) verwenden. Der Vorderkanal wird vom Benutzer-Agenten mit Umleitungen gehandhabt und erfordert keine Verbindungen zwischen IDP und SP. Der Rückkanal wird zwischen Komponenten wie IDP und SP abgewickelt. Einer der Gründe für die Verwendung des Rückkanals ist die Kontrolle. Wenn das Token widerrufen wird, behält der Entwickler die volle Kontrolle über die ordnungsgemäße Beendigung der Sitzung.
Mehr APIs
Eine weitere Neuheit ist eine Reihe von Identitäts-APIs, die wir in Bezug auf den Identitätsserver und die Benutzer-Selbstbedienung einsetzen können. Dies ist natürlich sehr wichtig für CIAM-Anwendungsfälle und ganz allgemein immer dann, wenn Sie Identitätsfunktionen in Ihre Anwendung einbetten möchten. Einige dieser Identitäts-APIs kennen wir bereits aus früheren Versionen, wie z.B. die SCIM2-API oder ihr Äquivalent, den Admin Service. Jetzt gibt es APIs, die es Ihnen folgendes ermöglichen:
- Verwendung der REST-APIs zur Kontowiederherstellung
- Verwendung der Self Sign-Up REST APIs
- Verwendung der Authentifizierungs-REST-APIs
- Verwendung der Consent Management REST APIs
- Verwendung der REST-APIs für den Export persönlicher Daten
- Verwendung der Konfigurationsverwaltungs-REST-APIs
- Verwendung der SCIM 2.0 REST-APIs
- Verwendung der OpenID Connect Dynamic Client Registration REST APIs
- Verwendung der OAuth2 Scopes REST-APIs
- Authentifizierungs- und Autorisierungs-REST-APIs
- Authentifizierungsdaten REST-API
Funktionen für Unterthemen
Mit dieser Version des Identity Servers können wir nun einige der häufig verwendeten Seiten mithilfe eines Unterthemas anpassen. Das heißt, wir definieren kein völlig neues Thema, sondern geben die Änderungen im Unterthema an. Dies ist eine Funktionalität, die wir auch im WSO2 API Manager sehen, wo wir ebenfalls die Unterstützung von Themen und Unterthemen für die Jaggery-Anwendungen wie Publisher und Store haben. Zu den unterstützten Seiten gehören z.B. die Anmelde- und die Wiederherstellungsseite.
Verbesserte Unterstützung für Log4j
Die bekannten Log4j-Eigenschaften haben sich in der neuen Version des Identity Servers zusammen mit der Möglichkeit, die Management UI zu ändern, geändert. Grund dafür ist, dass ab Kernel 4.5.x das carbon.logging jar nicht mehr verwendet wird und stattdessen die pax-logging-api eingesetzt wird. Bei diesem Upgrade wird auch die Log4j-Version auf Log4j2 aktualisiert. Änderungen müssen in der Log4j2-Eigenschaftendatei vorgenommen werden. In IS 5.9.0 wurde eine Korrelations-ID an allen Stellen hinzugefügt, an denen die Protokolle gedruckt werden. Die Korrelations-ID wird verwendet, um die Methodenaufrufe für eine einzelne Anfrage zu korrelieren. Die Korrelations-ID wird nach dem Zeitstempel gedruckt.
Migration
Die Umstellung von einer Version eines WSO2-Produkts auf eine andere erfordert häufig einen Migrationsprozess. In diesem Falle für Identity Server 5.9.0 lesen Sie bitte die Migrationsseiten online, um zu sehen, was für den Wechsel zur neuen Version getan werden muss. Beispielsweise müssen alle benutzerdefinierten OSGI-Bundles aufgrund der Änderungen am Carbon Kernel, den wir jetzt verwenden, neu kompiliert werden.
Roadmap
Die Roadmaps für WSO2-Produkte sind jetzt öffentlich und dienen als Richtlinie für zukünftige Versionen, natürlich mit dem Hinweis, dass sie nur zu Informationszwecken zur Verfügung gestellt werden. Hier befindet sich die Roadmap für WSO2 Identity Server. Für die einzelnen Szenarien ist kein Zeitrahmen wie Q2 20xx angegeben. Es ist natürlich gut zu wissen, was auf uns zukommen könnte. Eine andere Informationsquelle ist natürlich GitHub, wo wir sehen können, dass an der Version 5.10.0-m3 und der Version 6.0.0-m2 gearbeitet wird. Der Quellcode kann heruntergeladen und eingesehen werden, um zu sehen, woran WSO2 arbeitet.
Fazit
Die aktuelle Version des WSO2 Identity Server bietet Verbesserungen gegenüber der Vorgängerversion und baut gleichzeitig auf den bestehenden Funktionen auf. Selbstverständlich ist die Implementierung oder Aktualisierung des WSO2 Identity Servers keine triviale Aufgabe. Wir empfehlen Ihnen jedoch, sich mit dieser neuen Version (einschließlich der behobenen und offenen Probleme) zu befassen und zu prüfen, ob sie einen Mehrwert bietet. Natürlich sollten Sie auch die Vorteile früherer Upgrades in Betracht ziehen, wenn Sie noch nicht die neueste Version verwenden.
Möglicherweise haben Sie schon länger auf eine gute Gelegenheit gewartet, um auf Container umzusteigen, dann könnte diese neue Version der Auslöser sein. Es schadet aber auch nie, eine neue Version zu testen. Und wenn Ihnen gefällt, was diese Version bietet, helfen wir Ihnen gerne bei Ihrem Umsetzungsplan.