This page highlights the main changes made in the 82018.2 1 product release.
Changes to the distribution package
There are not substantial changes to the distrobution package for this release.
Reminder: Please note that within the prior release Java JRE is was no longer included in our the distribution package. The installation process has been modified to reflect this change. The Java version is now logged in the diagnostic logs to ease support tasks. Ubisecure will inform which Java version has been used for internal testing. Customers who wish to use a new Java version must perform their own testing or order additional testing. Both SSO and CustomerID can use Both CustomerID and SSO can utilise the same Java installation . See Documentation
What does this mean for our customers?
- Excluding Java from the installation media reduces the size and allows use of existing installations
- Faster customer environment Java upgrades independent of the Ubisecure release cycle
SSO Management API supports more use cases
SSO Management API enables system configuration without using the Management user interface. This REST based interface introduced first in SSO version 7.5 allows for automated management of connect applications, policies and access groups. See Documentation
Version 8.2 now allows
- Local administrative users and their groups to be managed
- Management of authentication methods
- Management of federation relationships
- Improvements to management of connected applications across various integration protocols
The SSO Management API endpoint is protected by OAuth2 and supports multiple users and access control.
What does this mean for our customers?
- DevOps style automation is now possible for all core management configuration use cases.
- Automation of configuration across environments (e.g. test, staging, production) can be scripted to remove risks of human error in configuration
OAuth2 and OpenID Connect related improvements
Our OAuth2 and OpenID Connect implementations have been under constant improvement. Many of the improvements relate to customer requirements often imposed by changes to legislation requiring message level encryption for all end points.
JWT Secured Authorization Request (JAR)
Until now, unlike SAML2 requests, OAuth2 authentication requests have not been signed nor encrypted. TLS level security provided transport level encryption and message integrity could be checked by the sender comparing values sent in the request to those received in the response.
Now signing and encryption are supported, using both symmetric and asymmetric keys. For asymmetric flows, public keys for signing of the messages we generate are published in the metadata. We encrypt using the public keys given at the time of registration of the other party in their metadata.
The userinfo and tokenintrospection endpoints now support signing and encryption.
Other OAuth2 and OpenID Connect related improvements
- OAuth applications can be managed using the OpenID Dynamic Client Registration protocol
- Provider metadata is now published at "well known location" and enables automated configuration of third-party software
What does this mean for our customers?
- The server describes its capabilities in a machine readable format that other systems integrating to it can read, interpret and use for their own configuration
- Our server reads advanced capabilities of connecting services from metadata and can update its own configuration without accessing a user interface.
High performance and high availability for session information
In-memory database cluster
Session information can now optionally be managed in an in-memory database cluster. A Redis Cluster as in-memory database is used which provides extreme performance and high-availability. Redis Cluster can be configured for linear scalability. See Documentation
This configuration is recommended for customers with high volumes of user accounts and high volume of session data usage.
The data which is stored in this high-performance database includes:
- User sessions
- SAML2 artifact messages
- SAML2 message IDs (for message tracking)
- OAuth2 refresh token
- PersistentIDs
What does this mean for our customers?
- Faster issuing and validation of access tokens
- Scalability to support massive commercial deployments with high-volumes of users and integrated applications
High availability for CustomerID
Complete support for using a multi-node PostgreSQL cluster
Identity Server 8.2 now contains complete support and configuration instructions for using a multi-node PostgreSQL cluster which enables high-availability in the event of an individual database node failure. Multiple database nodes should always be used for customers with high availability requirements. See Documentation
A new Health API (also known as ping endpoint) is provided in CustomerID for checking the status of each node in a cluster. Status of individual service components can be shown. See Documentation
What does this mean for our customers?
...
CustomerID 5.3
Primary features added to CustomerID assist end users understanding and managing their account status. Administrators will see that invited new users have a status of "Waiting for registration", meaning the end user will have been sent an email invitation to register onto their service, but has not registered yet. Once the user has submitted their registration, the end user and Administrator will both see the user account as "Pending", which means a system administrator still needs to approve or process the end user account application. Additionally, end users user interface has been updated to more clearly show the state of their federated account; specifically to easily unlink a previously federated account.
Please ensure that you review the CustomerID Change Log for other specific improvements and corrections found in this release.
SSO 8.3
SSO 8.3 has been substantially updated to include new functionally of the Ubisecure Backchannel Authentication Adaptor (UBAA). This is a step forward towards modularisation of the application. This initial release permits customers to utilize the Swedish BankID service within Identity Server. The UBAA requires updating of the SSO component and installation of the authentication adaptor itself.
Future authentication adaptors will utilize SSO and the UBAA with simple installation of a new authenticator module. Please ensure you see the SSO Change Log for high level details and links to installation instruction for UBAA.
Additional features include a new web based applications for SSO end user password reset, improvements in LDAP searching and a number of corrections for existing key functionality Management API enables system configuration without using the Management user interface. This REST based interface introduced first in SSO version 7.5 allows for automated management of connect applications, policies and access groups. See Documentation
New Knowledge Base articles
...