We are pleased to announce the release of Topicus KeyHub 19.1. In this release we finally bring a long wished for feature: provisioning of Azure Active Directory. Also, we've made a lot of improvements to the management of a clustered setup and continued our work on the auditor dashboard.
E-mail addresses must now be unique
TKH-1881 E-mail address are now guaranteed to be unique over all users across a Topicus KeyHub installation. This prevents problems with provisioning on targets that require the e-mail address to be unique, such as Microsoft Azure. It also allows the e-mail address to be used as identifier for SAML clients.
When multiple accounts share the same e-mail address, the account created first will keep the address. For the other accounts, the field will be cleared. When registering an account with an e-mail address already in use, the field will be left blank for the newly created account.
Microsoft Azure provisioning
TKH-1908 Topicus KeyHub now supports dynamic account provisioning on Microsoft Azure. Accounts can be created in an Azure Active Directory and assigned to directory roles, security groups and Microsoft 365 groups. It is also possible to setup the tenant and the provisioning to use single sign-on with Topicus KeyHub. This allows your users to login onto Azure directly from Topicus KeyHub.
Auditor dashboard and classifications
We have continued our work on the auditor dashboard and implemented the first criteria that can be set on a classification: a maximum audit interval.
TKH-1051It is now possible to set a maximum audit interval on a classification. Managers for groups that fall within this classification will be notified when the group does not conform to this audit interval. For example, when the maximum audit interval is set to 3 months and a group is only scheduled to be audited twice a year, the managers will get a notification on their dashboard. This notification also has button that allows the schedule to be adjusted with just a single click.
TKH-1865The values for managers and members on the dashboard now show the number active and inactive accounts if not all accounts in a group are active.
TKH-1919The details for a group now show all information, just as it is shown to the members of that group.
TKH-1920The group details contain a new section with warnings about that group. These warnings are also displayed to the members (and managers) of the group.
Many bigger and smaller improvements were made to the high availability setup of Topicus KeyHub. These improvements enhance the stability of the cluster and allow for much more flexibility when recovering from a failure.
TKH-1892 When restoring a database on a node, it is now possible to create a backup of the database on that node prior to it being overwritten. In the case of a mistake, this backup can be used to restore the original database.
TKH-1893 In the case of a hardware or network failure, it is not always possible to bring all nodes back up. A new node management screen allows nodes to be temporarily disabled and taken out of the cluster. This allows for a quick restoration of basic service on a lower number of nodes.
In addition to these significant improvements, the following smaller changes were made:
TKH-1882When trying to restore a database when no primary database is available, a proper error message is now displayed.
TKH-1884A spurious notification during installing updates about problems in the snapshotting system was fixed.
TKH-1887Restarting Pgpool on all nodes now continues when a single node is unreachable.
TKH-1890Nodes are now renumbered when a node is removed from the cluster, preventing ghost nodes to show up in Pgpool.
TKH-1897An error was fixed when applying changes to a cluster that required the application to restart.
TKH-1914The health check of a node could incorrectly report being available when in fact its database was read only.
TKH-1928Automated tasks did not run when Topicus KeyHub was setup with HA due to the inability to elect a cluster leader.
TKH-1933The option to enable trace logging for provisioning is now correctly synced across a cluster.
TKH-1869A test case was added for a full version upgrade in a cluster.
TKH-1911The button to directly go to a node with problems was removed because it was unclear which node was opened when multiple nodes had a failure.
TKH-1916The replication overview is now much more responsive because status is refreshed in the background.
The following smaller improvements and bug fixes were made:
TKH-1603Our test frameworks were upgraded to Spock 2 and Groovy 3.
TKH-1773The number of REST calls to read settings during tests was reduced drastically.
TKH-1808Documentation was added for the metrics endpoint.
TKH-1816A new audit record was added when vault records are moved, copied or shared.
TKH-1831The URL scheme was changed to be more resilient to special characters in names and to provide stable URLs even when names are changed.
TKH-1847For OIDC directories, the configuration endpoint is now used for status checks.
TKH-1872Trace logging was added to provisioning of custom attributes.
TKH-1880Our bot protection now is much faster in more browsers.
TKH-1883A locking issue was fixed during updates that could cause the user interface to become unresponsive.
TKH-1889The tools netcat and tcpdump are added to the installation base to aid in troubleshooting networking issues.
TKH-1900The description and messages regarding various notifications have been improved.
TKH-1904Special characters in certificate bundles are now ignored rather than causing the certificate chain generation to fail.
TKH-1905The colours used for the classifications on the auditor dashboard could get corrupted.
TKH-1909The installation step that waits for the application to be running could get confused if the system clock was changed while waiting.
TKH-1912The Linux CLI now correctly detects its path if the tool is executed via a symlink.
TKH-1917Static and dynamic provisioning can now be used for different groups on systems via a single group in Topicus KeyHub.
TKH-1926The size limit for files in the vault is now mentioned in the manual.
TKH-1929The application server was upgraded to WildFly 25.
TKH-1931With a pending 2FA reset request, a user could access some settings regarding 2FA configuration even when 2FA was supposed to be restricted in the directory.
TKH-1932Viewing a webhook for a group no longer gives errors when the webhook has deliveries.
TKH-1938The e-mail sent to a user when a 2FA reset is requested incorrectly listed the KeyHub administrators as being responsible for handling the request.
TKH-1946An error was fixed when changing configuration values for a single node in a cluster.