We are happy to announce the release of Topicus KeyHub 18.1 at the start of summer. With this release we offer the ability for an additional authorization step for group membership requests, leaving final approval up to a different group altogether. We also did some preparatory work for an upcoming "social recovery" feature for account passwords, including vault access, and we took some steps in the automation of our release pipeline. As usual, we implemented a number of smaller improvements and fixes for several issues.
Important notice: Undisclosed security vulnerability
TKH-1731 Internal auditing revealed that under some conditions permissions were not correctly checked against the right policies when operating directly on our back end. We strongly recommend all installations to be upgraded to 18.1. Topicus KeyHub customers can inquire for more information.
Authorizing groups for group membership
TKH-1721 We've added the ability for group managers to link a different KeyHub group to their group to authorize group memberships as an optional extra step. This enables organizations to have group membership approved by accounts who are not themselves a member of the requested group, such as department heads who are responsible for certain access privileges, but are not supposed to have or need that access themselves.
Group managers will still be responsible for the initial evaluation of a group membership request. After approval by a group manager, a subsequent request will be made to managers of the authorizing group (if configured). Only after this final approval will the requested membership be granted.
Upcoming "social recovery" feature
TKH-1741 We're in the process of adding an exciting new feature that will enable users to recover their account, including vault access, if they lost their password. After discussion with expert panels formed by some of our customers we designed a protocol based on Shamir's secret sharing. With this release we make some preparations in the back-end code to prepare for this functionality, which we expect to deliver in the coming months.
The following smaller improvements and bug fixes were made:
TKH-1651We limited the set of commands available through the Salt API in an effort to harden the security of our appliance.
TKH-1672We improved our release pipeline by automating most steps so that they can be run from our build server.
TKH-1673We now show the username as it will be used for a specific provisioned system, next to that system on a user's profile page.
TKH-1692The appliance manager no longer "hangs" in an incorrect state on a node newly added to a cluster.
TKH-1699We upgraded SaltStack to version 3003.
TKH-1701We now collect the exact versions used for every library, package and module during the build process as an aid in determining software security risks.
TKH-1705Pgpool should now be able to recover its connection automatically when a database becomes available again.
TKH-1712An error was fixed that prevented users from accessing a shared vault record when they're not allowed to see the group it is being shared from.
TKH-1738We fixed the description for several types of audit records.
TKH-1714The appliance should now automatically reboot after installing upgrades (if required).
TKH-1715We removed stacktrace logging for requests that lead to 4xx http response codes. Client errors should not result in log spam.
TKH-1716With help from several of our users we identified and fixed a possible login-loop when using SSO against KeyHub with a security key.
TKH-1717We added proper input validation checking in some query parameters of our REST API where it was missing.
TKH-1719Sending invalid JSON to our REST API now properly results in a HTTP 400 response.
TKH-1723Schedules for backups and updates are now validated before applying and invalid schedules result in proper error feedback.
TKH-1725Attempting to upload a license whose limits you've exceeded will now result in proper error feedback.
TKH-1726Audit records concerning a request will now contain a reference to that request so they can be grouped together more easily.
TKH-1732Accounts are now properly deprovisioned when removing a group on system, rather than showing an error.
TKH-1733We marked several properties throughout our REST API as read-only.
TKH-1735Pgpool has been upgraded to 4.2.3.
TKH-1736We improved the stability of several of our automated tests related to the activation of groups on the dashboard.
TKH-1742Removing a node from the cluster should no longer result in errors in the appliance manager that can only be resolved by logging out and in again.
TKH-1745We increased the early warning period for expiry of KeyHub's IDP certificate from two weeks to three months.
TKH-1746We improved the reliability of the url switch during KeyHub's installation process.
TKH-1751An issue was fixed that could cause a user to get stuck during re-registration.
TKH-1758Login via SSO on the appliance manager now also works when running multiple instances in a cluster.