About this release
- Former user (Deleted)
- Keith Uber
This page highlights the main changes made in the 8.2 product release.
Changes to the distribution package
Java JRE is no longer included in our 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 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?
- In the event of hardware or other database infrastructure failure, CustomerID will continue to serve customers while the issue is resolved
- Reduced system downtime
- Increased system performance by splitting requests across database nodes
New Knowledge Base articles
Remember to check our Knowledge Base section for the latest extending articles on use case configuration: