Access profiles in Topicus KeyHub 50 can now act upon future dates. Business rules can now return a validity range instead of a plain yes or no. This lets KeyHub automatically calculate when a membership begins or ends and handle the lifecycle actions itself. Additionally, auditors get their own provisioning dashboard, rotating the vault recovery key no longer requires using OpenSSL manually, and the directory and organizational unit screens have been redesigned. A long list of smaller improvements and fixes completes this release.
Until now an access profile only knew whether an account should be a member right at this moment. In this release it can work out when a membership or activation starts and ends, show that in advance, and do something about it when the date arrives. The whole feature requires the "Identity Lifecycle Management" license feature.
TKH-3893 Business rules for assignment and activation can return a validity range with a "from" and "to" date instead of only true or false. Membership or activation then starts and ends on those dates on its own, re-evaluated on every run, and scripts get the modern Temporal date API for working them out. Existing boolean, string and number rules behave exactly as they always did.
TKH-3894 Once a rule returns a validity range, KeyHub knows a transition is coming and shows it on the member's row. Accounts whose range only starts later, and accounts that recently left, are gathered under "Upcoming and recent transitions", so an owner is no longer guessing who is about to arrive or has just gone. Boolean rules cannot be predicted this way, but their transitions are still recorded as they happen.
TKH-3895 Lifecycle actions fire automatically a set number of days, weeks or months before or after a member is added, removed, activated or deactivated. Each occurrence becomes an event with its own status (pending, fired, failed or cancelled), kept as history for the same period as audit records. Actions timed before a transition need a validity range to know the date in advance, so boolean rules only support the "at or after" variants.
TKH-3896 The first action type is a mail action. Subject and body are Liquid templates, recipients can be an account attribute of format e-mail or a script, and the template can reach the member's account and identity data as well as details of the transition that triggered it. Templates are checked when you save the action, with line and column numbers on errors, and a template that misbehaves fails its own event instead of holding up the mail engine.
TKH-3897 Deleting an account normally cancels whatever lifecycle events are still pending for it. That is usually right, but not always: a farewell mail tied to the removal really should still go out. Ticking "fire pending lifecycle events now" on a manual account removal delivers those events first. Bulk and automated removals always cancel.
TKH-3912 An account leaving the organisational unit that owns an access profile is treated the same as a deletion, whether it moves, is removed from the unit, or the profile itself relocates. Pending events and predictions for that profile are cleared rather than firing later for someone who has already gone.
TKH-3925 Deleting an account attribute of format e-mail used to quietly drop it as a recipient from any lifecycle mail action, leaving that action to fail every single time it fired with no valid "To" address. Removing such an attribute is now refused, with a message naming the access profile that still needs it.
TKH-3926 A predicted activation date could fall after a member's predicted removal date, implying an account would still be active on a profile it had already left. Activation predictions are now clipped to the membership period.
TKH-3927 Predicted transitions are stored as one row per transition, each with its own type and date, rather than a fixed set of date columns per account. On screen that shows up as a tidier predictions table listing account, transition type and date, with a member's own row showing just the next transition ahead of it.
TKH-3928 Lifecycle actions and their events require the "Identity Lifecycle Management" license feature. Without it the lifecycle panels stay hidden and creating an action is refused. Dropping the licence removes existing lifecycle actions, their recipients and their events, and the licence-change preview says so before you confirm.
TKH-3929 Clearing a profile's assignment or activation rule left any future date it had projected stranded: unreachable without the rule, yet still advertised on the account's row and still driving any event scheduled off it. Removing a rule now reconciles those predictions straight away, keeping anything already in the past as history.
Sending a mail on a lifecycle event
Topicus KeyHub now has full support for unlocking your vaults using a security key. Setting one up for that purpose is easy, and being without it is not a dead end. It is also supported on directories that previously did not allow adding a security key at all.
TKH-2788 Adding a security key that supports it now asks straight away whether you also want to use it for unlocking your vaults, rather than that link quietly forming during some later sign-in. Answer there and then, or skip and decide later. Vault unlock can be switched off and on again at any time from the key's settings in your profile.
TKH-2789 Every screen that asks you to unlock your vaults, in the console and when signing in to an application, now offers both your security key and your password. The key is tried first because it is usually quicker, but one click switches to the password when the key is sitting at home, and back again whenever you like.
TKH-2791 Accounts in an OIDC directory (such as Entra ID) that enforces its own two-factor authentication could not register a security key at all, which is a shame given that a security key is exactly what makes unlocking a vault quick. Registration now has an extra, skippable step for adding one purely for vault unlock. Only keys that support it are accepted, and they are never used as a second factor, since verifying the sign-in stays the directory's job.
Using a security key to unlock your vault
TKH-3744 Rotating the vault recovery key used to be a manual exercise: generate an RSA key pair with openssl, then upload the public half. The Vault recovery page now handles it behind a single "Regenerate key" action. Topicus KeyHub generates the new pair itself and insists you download the private key before continuing.
From there you can upload the old private key so existing vaults are re-encrypted with the new one, or skip that step if the old key is gone for good. A new "Check private key" action lets an administrator verify a recovery key against the stored public key without changing anything, which is a reassuring thing to be able to do long before you actually need the key.
The vault recovery key
TKH-1711 Auditors get a fourth dashboard alongside the accounts, groups and service accounts dashboards: the provisioning dashboard. It lists every group on system in the organisational unit with its provisioned system, type, account provisioning mode, linked groups, access profiles and service accounts, and the group that owns it. Filters for organisational unit, system, owner group and type narrow the list down.
Four CSV exports cover the list itself plus its links to groups, access profiles and service accounts, so this overview no longer has to be pieced together from a separately generated report.
Auditor provisioning dashboard
Provisioning and identity source synchronisation received a batch of fixes, several of which were quietly costing either correctness or time.
TKH-3876 AFAS returns employee and contract data in pages, and without a stable sort order those pages could shift between requests on a large synchronisation, dropping or duplicating rows and leaving accounts with the wrong attributes. Every paginated request now asks AFAS to sort on the employee key.
TKH-3890 Outgoing SCIM user provisioning sent an e-mail address without ever marking it as the primary one, which service providers that insist on a primary address rejected outright. The address is now marked as primary, so provisioning to those systems gets past account creation.
TKH-3891 Provisioning a user to Microsoft Entra ID reported the attribute update as a write even when nothing about the account had changed. Every full synchronisation therefore looked dirty, sending a redundant update to Microsoft Graph and steadily shrinking the automatic full-sync interval. Attributes are now compared before being written, so an Entra ID connection settles down once its accounts are in sync.
TKH-3892 The automatic full-sync interval is meant to shrink towards 0, meaning a full synchronisation on every run, when a system keeps producing changes. A rounding issue kept it stuck at 1, so a busy system skipped every other run instead. It can now reach 0 as intended.
TKH-3902 Creating a group on system with the Terraform provider failed whenever the target system picks the name itself, an Entra ID security group with a generated UUID being the obvious case: Terraform saw the name that came back as an inconsistent result and aborted the apply. Such a group on system can now be created with just a display name, and the name KeyHub returns is accepted.
TKH-3903 AFAS hands over date and time values without a timezone. KeyHub now reads a zoneless value in AFAS's own timezone and passes it on with an explicit offset, instead of letting an ambiguous timestamp drift by an hour or two further down the line. A value that still cannot be parsed is dropped and logged rather than failing that employee's entire synchronisation.
TKH-3919 Linking the "Account-only provisioning" group on system to a SCIM system that has no concept of passwords could fail with an internal error and roll the whole action back, leaving no link at all. The password step is now skipped for systems that do not support it.
TKH-3959 Granting or revoking access in a clustered deployment could take several seconds, most of it spent on the internal provisioning cache replicating its state to every node on each read even when nothing had changed. The cache now writes only when a value actually changed, and no longer needs a cluster-wide check on every read just to expire old entries. Provisioning in a cluster is no longer waiting on its own bookkeeping.
Two more parts of the console have been brought in line with the layout introduced for linked systems.
TKH-3407 Every directory type now opens on its own details page, showing the UUID, the configured fields, its accounts with a link through to the full accounts overview, and its webhooks. Editing moved to a separate page that deliberately does not carry a delete button. Maintenance directories and pending accounts, which never had a page of their own, get the same read-only details view.
TKH-3408 Organisational units get an overview built on the searchable table used elsewhere in KeyHub, and a details page that gathers the name, owning group, description, settings, accounts and applications in one place rather than spreading them over tabs. Editing, moving groups, transferring ownership and deleting are separate actions reached from that page, so a stray click is much less likely to change something.
Internal directory details
TKH-3820 A temporary workaround that disabled the esp4, esp6 and rxrpc kernel modules on the appliance, put in place while an upstream kernel security fix was pending, has been removed now that AlmaLinux ships the patched kernel.
TKH-3952 TKH-3965 The application server has been upgraded from WildFly version 40.0.1 to version 41.0.0.
The following improvements and bug fixes both large and small were made:
TKH-3782 The record type filter on the audit log was a long dropdown you had to scroll through. It now has a search box, so a few letters get you there.
TKH-3857 Two groups that exclude each other could still both be added to the same access profile, which rather defeats the point of the exclusion. Adding the second one is now refused, with a message naming the group it conflicts with.
TKH-3899 Console forms gave no indication of which fields were required. Editable fields that may be left blank now carry an "optional" label, composite editors such as the vault's secret, file and end date fields included.
TKH-3901 Applying a firewall configuration whose custom monitoring port matched the appliance's built-in default of 9443 failed, because those two identical port numbers were not recognised as duplicates. The configuration now applies whichever ports are chosen.
TKH-3906 KeyHub tracks the expiry date of the server certificates behind webhooks, LDAP-based directories and provisioned LDAP or AD systems so it can warn before they lapse. The scan that reads that date did not present a client certificate, so endpoints requiring mutual TLS rejected the handshake and the expiry date was silently never recorded, even though ordinary traffic to those endpoints kept working fine. The scan now presents the configured client certificate as well.
TKH-3907 Trying to submit a request that a fellow group member had already opened produced a message implying you had an open request yourself. It now names the colleague who does, and asks you to wait until a manager or administrator has processed it.
TKH-3913 Webhook events already carried KeyHub's origin URL, which in a cluster does not tell you which node handled the event. Every push now carries the machine's hostname as well, taken from the server's configured hostname.
TKH-3914 Approving a group membership request whose end date had lapsed while it waited in the four-eyes queue dumped the reviewer on a generic error page. Reviewers now get a clear explanation, and when approving a membership update they can correct the end date there and then, the way join requests already worked.
TKH-3915 The manual's list of licensed features has been tidied up: the separate "SCIM" entry is gone, since SCIM has been part of Identity Lifecycle Management for some time.
TKH-3917 The pop-up that lists your matching records after "Fill with Topicus KeyHub" could sit there completely empty, because the background check confirming the pop-up is genuinely KeyHub's own sometimes never got an answer. That check is now retried instead of waited on indefinitely.
TKH-3918 A launchpad tile for an SSO application granted through an access profile only appeared if you also reached that application some other way, for instance as its technical administrator. Without that overlap the tile silently went missing, quietly defeating the point of granting it through the profile. Access profile members now get the permissions the tile needs directly.
TKH-3920 The OpenMetrics endpoint could answer with an HTTP 502 instead of metrics, because SELinux blocked the appliance's internal proxy from reaching the collector behind it. The proxy now has tightly scoped rules for metrics and OpenTelemetry traffic, so monitoring tools scraping the endpoint get their data.
TKH-3921 The audit log recorded a used activation code only during password recovery, so activating a brand new account left no trace at all, even though it uses the same code and the same endpoint. Both now write the same audit record.
TKH-3933 During a rolling cluster upgrade, cycling the database primary node left a short window in which the cluster could not process database writes, because the standby was only promoted once the old primary had stopped responding. The upgrade sequence now hands the primary role over before stopping the old primary's database.
TKH-3934 A licence key signed with a signing key this version does not recognise, or one missing its signing key ID altogether, crashed with a generic error page. Both cases now explain themselves, including the likely cause that the key was issued for a newer version.
TKH-3935 When an account was matched into more than one directory-backed access profile, the activation code generated for the first match could be overwritten before the activation e-mail was rendered, so the invitation was silently never sent. The code is now saved as soon as it is generated.
TKH-3936 Opening the autofill pop-up again immediately after closing it, when filling two fields in a row for instance, could make the second one close itself before it showed anything. Each attempt now keeps its own record of the authenticity check rather than sharing one.
TKH-3937 TKH-3939 TKH-3942 TKH-3944 TKH-3950 TKH-3954 Various improvements were made to the reliability of the automated test suite.
TKH-3940 After applying a cluster configuration change, such as saving or removing nodes, the page could look frozen: every checklist step complete, but the browser never returning to the cluster overview. It now returns reliably once the change has finished applying.
TKH-3941 OCSP stapling is switched on by default in the appliance's proxy, but for certificates whose responder used plain HTTP, SELinux blocked the outbound request and produced a steady trickle of error and audit log entries that could not be turned off. TLS handshakes themselves were never affected. The proxy can now reach those responders, so stapling does what it says and the log noise is gone.
TKH-3943 Removing a node from a cluster could take far longer than expected, or appear to hang altogether, because the remaining nodes restarted an internal management service that did not need restarting. That restart is now skipped.
TKH-3945 In a narrow timing window, clicking Back on the "Register the first user" step of the installation wizard could land on an error page instead of the previous step.
TKH-3946 A brief database failover during a cluster backup crashed the backup outright instead of retrying it, taking down any update that depended on that backup. The retry now works as intended.
TKH-3955 A clustered node whose internal singleton service failed to start could quietly claim to be a second cluster master, running the same scheduled jobs as the properly elected node while still reporting itself as healthy, so automatic recovery never stepped in. Such a node is now reported as unhealthy and restarted.
TKH-3957 The timing histograms on the OpenMetrics endpoint, database latency among them, reported everything in a single bucket, which makes percentiles and latency trends impossible to chart. Tailored bucket boundaries now make them usable. Separately, synchronisation and provisioning operation logs stamped every entry's end time moments after its start time regardless of how long the work actually took; the real duration is now recorded.
TKH-3958 The autofill pop-up verifies that it was genuinely opened by the KeyHub extension, so a look-alike page cannot present a fake copy of it. That verification token used to sit briefly in the pop-up's own markup, where a hosting page could read it, and it only decided which records were shown rather than whether a fill actually went ahead. The token no longer touches the page, and a field is filled only once the pop-up has proven itself.
TKH-3960 A burst of concurrent unauthenticated requests to the login page could corrupt the internal record of in-progress OpenID Connect sign-in attempts and leave a server thread spinning at full CPU until the application was restarted. That tracking is now properly synchronised, so a flood of login requests, from automated scanning traffic for example, can no longer wedge a thread.