2020 marked the start of a whole new decade, which was pretty special. But, for all of us in the WSO2 Identity Server team, it means even more because we released one of our most feature-packed versions yet—WSO2 Identity Server 5.10.0.
If you want to learn about the additions in-depth, sign up for our product release webinar over here.
WSO2 Identity Server now supports passwordless authentication using FIDO2. This is based on the security model developed as a joint effort between the FIDO Alliance and the World Wide Web Consortium (W3C).
Passwordless authentication eliminates all forms of risks associated with passwords, such as phishing attacks, replay attacks, etc. It also brings enhanced convenience as users can unlock login credentials using a wide range of choices, e.g., fingerprint readers, web cameras, or an easy-to-use FIDO security key.
The all-new Self-care Portal
This is a major revamp, over the previous Jaggery-based Self-care Portal; we have completely rewritten it using React. The new Identity Server Self-care (User Portal) provides an excellent user-friendly UX, and it consumes the new and improved RESTful APIs introduced from the previous release.
An intuitive user interface provides excellent user convenience. Therefore, the self-care portal plays an important role in our developer-focused CIAM journey.
The following set of features are available out of the box:
- User profile management
- Linked accounts
- Export user profile
- Reset password
- Account recovery
- Manage authentication factors
- Monitor active user sessions
- Consent management
- Review pending approvals
- Application Listing
More from REST APIs
In the previous release, we introduced a new set of REST APIs for core management capabilities and end-user interactions. In this release, we have done the following modifications to this set.
- Identity Provider Management
- Email Template Management
- User store Management
- Keystore Management
- Application Management
- OpenID Connect Scope Management
- Governance Connectors Management
- Script Library Management
- User Discoverable Application Management
Scope-based authorization for internal REST APIs
Authorizations for internal REST APIs in the WSO2 Identity Server are done via permissions. The calling user must belong to a role that holds the minimum required permission level.
Besides, users can obtain an access token via OAuth flows and then use it to consume internal APIs. We now support scope-based authorizations for such requests. Application developers or system administrators would directly benefit as this will allow them to utilize the flexibility of the OAuth framework with internal REST APIs.
Refer to the official documentation, to learn further details on how it can be used.
Support for a unique user ID
In prior product versions, a username was considered an immutable attribute. There was no other identifier available to uniquely identify a user, other than by using an SCIM ID. However, even that was only applicable to SCIM-enabled user stores.
The lack of a unique user identifier introduced multiple bottlenecks to many features, including username renaming, multi-attribute login capabilities, and RESTful APIs for admin users.
From this release onwards, we introduce an immutable unique user identifier across the system, and it maintains a mapping with all other user attributes. This will eventually allow the product to eliminate all the aforementioned bottlenecks.
We have also introduced a new set of user store managers to work with the unique user identifier, by deprecating their existing counterparts. Such user store managers would be for JDBC, Read-only LDAP, Read-write LDAP, and Active Directory. Backward compatibility with previous user store managers is guaranteed with this product release.
Not only those…
Other than the highlights of the new features and improvements mentioned above, we have done many improvements. You can find all the details here.
Planning to migrate to the new version?
We understand that some of the features packed with this release bring complexities for existing deployments that are trying to migrate. This particularly affects new unique user ID implementations. Because of this, we have handled many of the backward compatibilities in the code itself to enable a seamless migration.
But still, there can be unavoidable changes required for the new features to work, such as schema changes. And for that, we have carefully updated our migration process alongside this release to support a seamless migration. You can find the latest migration process documented here.
We are currently working on revamping the Admin Portal, to follow suit with the self-care portal. And we plan to ship it over the next releases.
Until then, you can join our mailing lists and engage with our developers directly. You can also participate in discussions related to the product in the architecture mailing list.
If you have any questions regarding the product, you can use our Stack Overflow forum to raise them as well. You can also reach out via email@example.com, firstname.lastname@example.org, email@example.com, Stack Overflow, Twitter, and Slack.