Just recently, WSO2 announced the release of the new Identity Server 5.9.0. Fear not, it’s still the award-winning product that supports the functionality that you are familiar with. Whenever there’s a new version of the WSO2 products I’m always anxious to learn what’s new. In this case with the Identity Server the changes are minimal, from 5.8.0 to 5.9.0 is just a minor step. Nonetheless, there are some things that are noteworthy.
First of all, this is one of a new generation of WSO2 products that run on the Carbon 4.5.x version, also known as Minsky. Minsky is able to run on Java 11, which of course is a big leap from the current products that are running on Java 8, a version that is already several years old. For now, you can continue to use Java 8 if that’s what you prefer, but it’s nice to know that you can migrate whenever you’re ready.
We have three major WSO2 Carbon platforms now, Wilkens (4.4.x), Hamming (5.2.x) and Minsky (4.5.x). If you’re wondering how they are naming these platforms? The answer is that they’re all Turing Award winners, between 1967 and 1969. Wilkinson will be the next platform version if WSO2 sticks to this way of name giving.
A new configuration model
There’s a new configuration model in Carbon 4.5, and that’s good news. For those of you who already are familiar with the WSO2 products, you’ll know that there are multiple configuration files in the [IS_HOME]/repository/conf directory.
There’s the axis2 file, carbon.xml, master-data sources.xml etcetera. Now, with the Identity Server 5.9.0, we have one master configuration file to rule them all. The old XML files are still there, but the deployment.toml is a global file that houses most of the configurations for the product. To quote WSO2: “Users will only see the mandatory and essential configurations that are in the product.’’ And this is a big improvement because anyone who has ever done configurations, knows the challenges that lie within. There’s the sheer volume of configuration files, multiple options to configure and different locations, to mention just a few of the issues. That also makes deployment time consuming, because the configuration touches many files.
Even maintaining an Ansible script means that you need to identify and incorporate all of the XML files where you want to do configuration changes. The deployment.toml, as the file is now called, is the one file that needs to be changed and it will push the changes to the XML files. You can still use the old XML files if you like, so any investment in Ansible playbooks are not necessary wasted because of this new functionality. Just remove the deployment.toml file in order to revert back to the old xml-based configuration.
Cross protocol logout
One of the big changes is that we can now do a single logout across multiple protocols. So that means SAML, Open ID Connect, etcetera (as shown in the image below), enabling you to do single log out across multiple protocols. One caveat though: in relation to SAML applications, cross protocol logout is only supported for SAML applications that use back channel (for example, synchronous) logout. Front channel is handled by the user-agent with redirects and doesn’t require connections between IDP and SP. Back channel is handled between components like IDP and SP. One of the reasons to use back channel is control. Whenever the token gets revoked, the developer retains full control over the graceful termination of the session.
More APIs
Another new thing is a number of Identity APIs that we can use with regards to the Identity Server and user self-service. Obviously, this is very relevant for CIAM use cases, and more in general whenever you want to embed identity functionality inside your app. We already know some of these Identity APIs from previous versions, like the SCIM2 API, or their admin service equivalent. There are now APIs that will let you:
- Use the Account Recovery REST APIs
- Use the Self Sign-Up REST APIs
- Use the Authentication REST APIs
- Use the Consent Management REST APIs
- Use the Personal Information Export REST APIs
- Use the Configuration Management REST APIs
- Use the SCIM 2.0 REST APIs
- Use the OpenID Connect Dynamic Client Registration REST APIs
- Use OAuth2 Scopes REST APIs
- Authenticating and Authorizing REST APIs
- Authentication Data REST API
Sub theme capabilities
With this version of the Identity Server, we are now able to customize some of the often used pages using a sub theme. This means that we are not defining a completely new theme, but basically indicate the changes in the sub theme. This is a functionality that we also see in the WSO2 API Manager, where we also have the theme and sub theme support for the Jaggery apps like Publisher and Store. Supported pages are for instance the signup and the recovery page.
Enhanced support for Log4j
The famous Log4j properties have changed in the new version of the Identity Server together with the Management UI possibility to change. Reason is that from Kernel 4.5.x onwards the carbon.logging jar is not used anymore and the pax-logging-api is used instead. With this upgrade the Log4j version is also updated to Log4j2. Changes need to be done in the Log4j2 properties file. On a side node, IS 5.9.0 now has a correlation ID is added to all the places where the logs are printed. The correlation ID is used to correlate the method calls made for a single request. The correlation ID is printed after the timestamp.
Migration
Moving from one version of a WSO2 product to another one, often requires a migration process. In this case for Identity Server 5.9.0 please read the migration pages online to see what needs to be done in order to move to the new version. For instance, any custom OSGI bundles, need to be recompiled due to the changes to the Carbon Kernel that we now use.
Roadmap
The roadmaps for WSO2 products are public now and serve as a guide to future releases, with of course a disclaimer that they are shared for INFORMATIONAL purposes only. This is the location of the WSO2 Identity Server roadmap. There is no indication of any timeframe like Q2 of 20xx for each of the scenarios. Of course, it is good to know what might be ahead. Another source of information is of course GitHub, where we can see that there is work going on for version 5.10.0-m3 and version 6.0.0-m2. The source can be downloaded and inspected to see what WSO2 is working on.
Conclusion
The new version of the WSO2 Identity Server offers improvements over the previous version while building on its existing capabilities. Of course, implementing or updating of the WSO2 Identity Server is not a trivial task. But we would advise you to look into this new version (including fixed and open issues) and see if it would add value. Obviously, if you’re not yet on the most recent version, you should also take the merits of previous upgrades into account.
Perhaps you were waiting for a good opportunity to make the move to containers for some time, then this new release might just be the trigger. But really, it never hurts to give a new release a test run anyway. And if you like what it brings, we would be more than happy to help you with your implementation plan.
