Topicus KeyHub works according to the principle central authentication, decentral authorisation. This means that every user authenticates against a single identity provider. After authentication that user will be granted authorisation and permissions according to the various groups of which he/she is a member. These groups are managed by various group managers, who are responsible for their group.

This manual is devided into several parts. After the Getting Started section where many tips and tricks are described, the next part is all about the functionality for regular users. This contains chapters about registration of new accounts and the daily use of Topicus KeyHub. The section that follows is especially for KeyHub-administrators and group managers who can performed advanced tasks like setting up new single sign-on connections. Finally the last section contains information about the Open Virtual Appliance (OVA).

Topicus KeyHub supports just-in-time account registration. Just follow the URL for your specific Topicus KeyHub instance (something like https://keyhub.<your_organisation>.com), enter your username and just follow the steps on the screen. The username is probably the same as the one you need for your corporate email.

Topicus KeyHub comes with a browser extension for Google Chrome and Mozilla Firefox. With this extension applying passwords and 2FA-codes becomes even easier. Go to www.topicus-keyhub.com/browser-extensions and click on the extension for your browser.

After installing the extension, go to Topicus KeyHub and in 'Profile > Settings' you can enable the browser extension by connecting Topicus KeyHub with it.

You can test the browser extension by clicking on the icon in the top-right corner of your screen. If successfully connected, all your password vaults should become visible.

If your organisation uses the 2-factor authentication solution of Topicus KeyHub, you can download the Topicus KeyHub-app to your phone. You can find the app in the respective app-stores of Apple and Android. With this app installed, you will receive a push-notification when Topicus KeyHub requires it. Just click 'Login' in the notification and you are logged in.

If you do not want to install the Topicus KeyHub-app, you can also use a similar TOTP-based app like the Google Authenticator or Microsoft Authenticator as a two-factor authentication solution. Although these apps work fine themselves, you will not receive a push-notification and you are required to manually enter the 6-digit code.

In addition to TOTP-based solutions, you can also use a FIDO2 compatible security key for 2-factor authentication. Topicus KeyHub fully supports the WebAuthn protocol, which means that you can use any compatible hardware security key (sometimes also called a "dongle").

On some devices your operating system can even function as a software security key, which means you can use, for example, the built-in fingerprint scanner as your second factor.

Topicus KeyHub comes with this context-sensitive manual. This means that whenever you press the questionmark-symbol at the bottom-left in Topicus KeyHub, this manual opens in a new browser tab at the corresponding section.

Topicus KeyHub comes with a personal vault which is like your password manager. You can find this vault in the Vault-section and this safe is meant for all your personal, professional credentials. For example your username/password for your time management, sick-leave application or all other applications you use with your personal credentials.

In Topicus KeyHub all authorisations are assigned through groups. Every group could provide access to one or more single sign-on applications, servers and/or a password safe for that group. The responsibility for the access a group provides and for its members are in the hands of the group manager(s). You can request access to the groups you require. Navigate to My Groups and click on 'Request'. Now a list of all groups is shown, grouped by group name. Click on a specific group, enter an optional reason and click on the 'request access' button to request access to that group.

Besides your personal vault Topicus KeyHub contains group vaults as well. Every group has its own vault to store and share passwords, 2FA-codes and files with other group members. Whenever you want to store a new secret like a password in Topicus KeyHub, you decide which group this secret belongs to and create a new vault record. Topicus KeyHub offers a password generator to generate strong secrets for new or updated credentials. After saving a new vault record in a group vault, every member of that vault immediately has access to that secret.

In Topicus KeyHub every user has its own profile settings under Settings at the bottom left of the Topicus KeyHub interface. Here you can change your language-settings, upload your SSH-key and consult your active sessions and user ids.

Whenever you have to change phones, you will need to register your new device to generate 2FA-code again. If you still have your old phone in possession, you can easily reconfigure your 2FA from your Profile-page. If you lost your old phone, you can request a 2FA-reset from the Topicus KeyHub login-screen. Such requests always require another user from your organisation to approve them.

Topicus KeyHub offers the possibility of uploading your SSH-key. This key is provisioned when a group is activated that grants access to a UNIX-based system. After activating the group, you can logon using your SSH-key.

Every group should have at least one group manager, and preferably two or more. A group manager is responsible for all members of that specific group and for all the access that group provides. Group managers can approve or decline group-access-requests and assign new group managers.

In most cases an account for Topicus KeyHub can be registered manually. Following the Register option on the screen a three-step workflow is presented to setup an account.

Registration of a Topicus KeyHub account can also occur by using a registration code. On the login-screen the option I have a registration code is available (or click on the link in the corresponding e-mail). The registration code can be entered in the next screen.

After submitting the activation code the account details are displayed.

If the account details are correct, the next step is to choose a password. This password should consist of a minimum number of characters. Be advised that specific words or characters are considered invalid and will therefore not contribute to the total number of characters of a password.

The next step is to setup 2-factor authentication. For a detailed description see the corresponding paragraph enabling two-factor-authentication.

In some cases it is necessary to reconfigure 2FA, for example when the security key or smartphone is broken or stolen. In order to reset 2FA it is required that the 2FA is disabled for that specific account. Users can request to disable 2FA themselves on the login-screen using the option I cannot use 2FA anymore.

Clicking that specific button leads to the following page:

To reset 2FA a mandatory reason should be entered. The request to disable 2FA is then to be judged by another user in the organisation. If the request is granted, the user and the other user are notified by e-mail.

If the user has forgotten his or her password, a request to recover the password can be submitted via I forgot my password. The procedure for recovering a password differs per account type and depends on the options chosen for the password. The different procedures are discussed below.

In some cases the following message can be displayed when signing in to Topicus KeyHub. This occurs when the password (no longer) complies to the criteria set by Topicus KeyHub. The password could be too short or the user could not yet have a personal password vault due to preliminary ending the registration wizard before. In this case the user will be guided through a three-step process in order to pick a new password. As this process is equivalent to the registration wizard, see the corresponding section in chapter 8 for more information about password usage and this three-step process.

A user can choose for password synchronisation between Topicus KeyHub and the directory. When the password is changed on the directory, Topicus KeyHub will detect this at logon and prompt the user for re-synchronisation. Topicus KeyHub will need the old and the new password to update the keys for vault. When the new password does not meet the password requirements set by Topicus KeyHub, the user will be asked to choose a new password.

Topicus KeyHub can act as a SSO-provider as well. If such a SSO-connection is present, the login-screen of Topicus KeyHub will be displayed instead of the login-screen of the target application. The first time a SSO-connection is used, the user is asked for his/her consent.

The following screen is then displayed:

Single Sign-On in Topicus KeyHub is provided through groups. This means that when a user tries to use SSO to an application without being a member of the corresponding group, the following screen will be displayed. This screen shows the group that the user should request in order to use SSO.

If a separate device is used to generate verification codes, the internal clock of such a device can fall behind KeyHub’s system clock. KeyHub will detect such an offset and will automatically apply a compensation. In exceptional cases, the shift may be too large to automatically compensate. When that happens, KeyHub will ask the user to input two consecutively generated codes, to verify the offset.

To gain access to the linked systems of a group, that group has to be activated. Click on a group to activate the user’s account(s) for one hour by default.

The desired end time for the activation can be set with the slider. The set activation duration will be set automatically with the next activation of the group. After the time period has expired, access to the group will be automatically deactivated. Access to a group can also be immediately deactivated by clicking on the group again. With manual deactivation of a group, the remembered activation duration is reset to the default of one hour.

A group can be configured with extended access. For groups with extended access, a button for Extended access will be displayed after activating the group. Clicking this button leads to the following screen::

The reason for extended access can be supplied and a request will be sent to the group managers. If the request is granted, this group will be displayed on the dashboard as:

Some groups require an explicit reason before activation is possible. This reason will be part of the audit trail and can be used for reporting purposes. If a group is configured with a mandatory reason, the following screen will be shown after clicking the group:

For a group it can be configured that authorisation is required for activation. In that case the screen below will be displayed on activation. After sending the request, a member of the authorising group will review this request. If accepted, the group will be activated with an end time of one hour in the future. The user can subsequently extend the activation himself during the permitted period. The end of the period is shown with a red triangle on the timeline. When the group becomes inactive, it can be reactivated, as long as this falls within the permitted period. If authorisation is combined with a reason, the reason for the request will be mandatory and recorded in the audit trail.

Groups can be combined into folders. Activating a folder activates all groups that are part of that folder at once. Click on Manage layout…​ to create and name folders for the user dashboard.

The screen for dashboard layout shows a list of all folders and the groups that are present within these folders. Every folder is displayed separately on the dashboard. Activating a folder activates all groups within that folder at once.

To add groups to a folder, a group can be dragged into a folder. Groups in the folder hidden groups are hidden on the dashboard. Hidden groups will not be visible by default but can be shown by pressing show all groups on the dashboard.

Click on Add folder at the top right side of the screen to create a new folder.

Each folder can be assigned a name. Pay attention to the name and choose a name that describes the purpose of the underlying groups. After clicking on Save the folder is added to the Dashboard layout and groups can be assigned to the folder. Click on the icon next to the group name to change the name.

A group manager can manually add a tile to a group. For a manually added tile, the following information must be provided:

A tile for an SSO application is created at the application itself by the technical manager of the application concerned. The tile is displayed for all groups that have access to the application. The name of the application is used as the title of the tile. For a tile for an SSO application, the following information must be provided:

A tile for a vault record is created at the vault record itself. Only managers of a group can make a vault record available as a tile on the launchpad. For the title and link of the tile, the name and link of the vault record are used. On a tile for a vault record, only the logo can be specified:

To join a group the access has to be requested by clicking the button Request on the top right corner of the screen.

Every user can request access to a specific group. Each request has to be granted by at least one group manager. To speed up this process the access request can be provided with a specific reason. This reason may help the group managers decide whether or not to grant access. After access is granted, the group will be shown at My groups and on the dashboard if applicable.

If a new group is required, a request can be send to create a new group. Click on Request new group at the top right corner of the screen to request a new group.

Every user can request a new group. A clear name should be chosen for the group that meets any requirements shown in the field. In the selection box the user can choose from prefixes that are already used within the Topicus KeyHub installation. If such a request is granted the requesting user will automatically be assigned group manager of the new group.

The requests for new groups are verified by a central management group and at least one manager has to grant the request. To speed up this process the request can be provided with a reason as of why this new group is required. After submitting the request, the pending request will be shown on the dashboard.

To send the group managers an e-mail, the link mail manager can be used. To leave a group the button Leave group can be clicked. After leaving a group the user has to request access to the group again if necessary.

After opening a group, a detail screen is displayed with the following information:

For each group contact can be made with the managers of the group via mail manager. A group can also be left via Leave group. Please note that once a group is left, access must be requested and approved again in order to regain access to the group. To request to remove the group use the remove button. This requires permission of a KeyHub administrator.

For a manager of a group, it is possible to edit the properties of a group. A group consists of the following properties:

The management of the members of the group is also the responsibility of a group manager. Existing members can be edited or removed by clicking on them. Click on Add to add a new user directly to the group. In the popup, the user must also choose whether this new user becomes a manager or a standard user. When a group membership is given an end date, the user will automatically be removed from the group when the date expires.

Groups can be audited. This means that a group manager performs an audit on the group members and this audit is stored in Topicus KeyHub. An audit can be performed at any time and the event of an audit is stored in the audit trail.

Audits can be viewed via the details of a group. For managers this page also offers the possibility to start a new audit with the add button.

Every audit can contain a general description, for example with the reason of the audit. Additionally, every group member can be audited on whether the accounts is still valid for this group and possesses the correct role in the group.

Each group member can be audited by either checking the checkmark on the left. This indicates that the group member is valid. If a group member is not supposed to be part of the group, the group member can be removed from the group by checking the red cross on the right side. If a group member has the group manager role, the group manager can be reassigned to a regular group member by checking the middle, yellow icon. New members (or managers) can be added to the group as part of the audit via the add button.

For every group member an optional description can be added, for example to explain why this member was removed by this audit.

Only after saving the entire group audit are the changes put into effect. If an audit is saved as a draft, it can be further edited and saved later. Only one draft audit can exist per group. A draft is only visible to managers of the group and does not count in the audit schedule.

A group can be configured to require audits be reviewed by another group. If this is set, an audit will be put 'under review' when saved. A message will automatically be sent to the members of the reviewing group. The audit in review will be put back in draft if there is a change in membership within the group. A manager of the group will have to redo the audit and resubmit for review.

When performing a review of an audit, all actions and comments are displayed. These actions must be reviewed and then the audit must be either approved or rejected. When reviewing the audit, feedback can be given to the manager of the group.

A group can be nested within another group. The nested group will automatically inherit the group memberships from the parent group. Changes to parent group memberships affect the nested group immediately. With a nested group, it is still possible for a user to be a member of the group directly. In the event that the user is a direct member of both the nested and parent groups, the nested group’s direct membership properties will take precedence over those of the parent group. In this way, for example, a user can be made manager of the nested group, while being a normal member of the parent group. If an end date is set to a nested direct membership, the membership will be converted to a nested membership upon reaching that date.

When requesting nesting of a group, it can be specified how to deal with existing memberships:

If a group is nested under another group, accounts inherited from the parent group will be hidden by default. It is possible to open these accounts and convert them to direct membership as part of an audit.

If a group has one or more nested groups under it (directly or nested under a nested group), these nested groups can be audited directly under certain conditions. All members of the nested group must originate from the nesting, and therefore not be direct. If the nested group has a designated authorizing group for audits, this should be set to the same as on the group being audited. All nested groups are displayed, and for each group it can choosen whether it will be directly included in the audit or not.

Within a group, another group can be designated for delegation of manager privileges. All members of the designated group are granted these delegated privileges. This allows the members of this group to perform management for the group without being a member of the group themselves. It allows them to perform the following operations:

Since they are not members of the group itself, they do not have access to:

To prevent the delegated privileges group from becoming too much of a concentration of rights, it is mandatory to set up an authorizing group for membership before delegated manager privileges can be issued. Any addition or update to the members of the group must therefore be additionally approved. It is also not possible for users to add themselves to the group.

A group that delegates its manager privileges cannot be nested or itself have nested groups.

Removing a group from Topicus KeyHub requires permission of a KeyHub administrator. After repeating the name and an optional reason, this request will be send to the KeyHub administrators. Until the request is approved, the group is still visible and active.

If a group is deleted, all elements that are attached to the group are also deleted. Elements that are removed are:

In some cases, a group cannot be deleted because there are elements attached to it that are not (directly) removable. The non-removable elements are shown in red on the page. Elements that cannot be removed are:

A vault consists of one or more vault records. Clicking on the Add record-button at the top right corner opens the screen to add a new vault record.

Each vault record consists of multiple fields.

The following fields are encrypted and are therefore protected against (database) breaches.

Any vault record can be modified by clicking on the record.

A vault record can have an optional end date. When a vault record expires though, the secrets are still valid and can still be used. Providing an expiry date is especially useful for notifying all group member of the fact that a certain secret should be renewed.

This warning is displayed at the vault record page as well. Notifications of all expired vault records for the logged-in user are displayed on the dashboard.

Each vault record with an end date can be assigned a notification period as well. After providing the end date, this field will be visible and can be changed when required.

The strength of each password in the vault is estimated. If the password is not assessed as very strong, this strength is displayed after the name of the vault record. Depending on the strength, the user is encouraged to a greater or lesser extent to change the password:

A password may also contain an indication for a duplicate password. Reusing the same password for different services is unwise. If the passwords belong to different services, they should both be changed.

The button behind the name of the vault serves to move, copy or share the record to another vault. These actions can only be performed by the manager of the group or the owner of the personal vault. If a record is shared with one or more other vaults, any change to the original will be immediately applied in all other safes. The name of a shared copy will not be overridden, if it has been modified within the vault it resides. The shared copies can be deleted, whereby the original will remain. If the original is deleted, all shared copies will also be deleted. It is also possible to specify a time period for sharing by selecting a period or a specific end date, so that the shared copy is automatically deleted after this time period has elapsed.

Management of a vault is the responsibility of the corresponding group manager. Each new group member automatically gains access to the vault and the vault records. As the vault records are encrypted with the password of each user, a password reset of a user withdraws access to the vault records. In such an event, the user will be presented the following message:

Here the user can request the group managers to restore access to the vault of the specific group.

Every user of Topicus KeyHub has its own personal password vault. This vault is only accessible to the user and it is not possible for other users to request access to a personal vault. It is possible to move vault records from the personal vault to another shared vault.

With the 'Export' button the contents of a vault can be exported as a CSV file. Only the personal vault or a vault of a group of which the user is a manager can be exported.

For groups where Application administration is enabled, applications and linked systems can be created and edited. The administration of an application and linked system includes the technical configuration of the application including webhooks. The technical administrator can add groups to a linked system or application, giving that group access to the system or application. This request must be approved by a person responsible for the application or linking group (see below). For more information on these topics, see the chapter on applications or the chapter on linked systems.

Applications and groups on linked systems are a responsibility of the group managers of the appointed groups. Decisions on whether to grant access to a group on system or an application are the responsibility of the group managers. Transferring the technical management or the responsibility to another group is possible. This request has to be granted by a manager of the receiving group.

Access to an application can have two meanings, depending on the type of application and the configuration. The most common relationship is SSO: the users of the group can use SSO log on to the application. The exception is the OAuth2 client, where the application itself has access to the data of the group in Topicus KeyHub, such as its vault. It is also possible that an OAuth2 client will be granted permissions that normally belong to the members of the group.

The following property can be set with an SSO application:

For an OAuth2 client, the granted permissions are shown. These permissions can be revoked if desired. See the chapter on permissions for OAuth 2.0 clients for more details on these permissions.

The following property can be set for a group on a linked system:

Managers of the owning group of an internal directory can see and manage the accounts of the directory via Manage access. They can do this by opening the internal directory and navigating to accounts.

After opening an access profile, a detail screen is displayed with the following information:

Via Edit, a number of properties of the access profile can be edited:

Attributes of Topicus KeyHub accounts can be managed by means of an access profile. To do this, the access profile must first be linked to a directory. With an access profile that is linked to a directory, only users from that directory can be members. Topicus KeyHub has a number of standard attributes, such as user name, primary e-mail address, first name, etc. In addition, it is possible to define your own attributes. These attributes can then be used to create accounts on linked systems.

Access profiles have members just like groups. The attribute rules of the access profile apply to these members. The members also get access to the linked systems and applications of the access profile. Unlike groups, the member management of an access profile is not done by the other members but by a designated group. All members of this designated group can add and remove users from the access profile, even if they are not members of the access profile themselves.

Groups can be linked to an access profile. Users who join the access profile are automatically invited to join these groups. These requests must first be approved by managers of the groups, just like normal group membership requests.

An access profile can, as the name implies, provide access to certain applications or systems. Access via an access profile is always available to a user. Unlike access via groups, there is no possibility for dynamic activation. Activation of the accounts is determined by a business rule or can be manually overwritten. If the membership has the status active, any accounts on linked systems are activated immediately and the user can log in to linked applications.

Under the Attribute Definitions tab, custom attributes can be defined. These attributes can then be used in access profiles. An attribute definition has the following properties:

An attribute definition has one of the following formats:

You can filter on various criteria. After selecting the criteria, press SEARCH to list the events that match the specified criteria.

The csv file contains the following values:

The first page that is shown is the Account tab. This screen shows the most relevant details of the current account. Changes regarding security and interface settings can be applied here as well.