Users Overview

Heimdall currently provides a built-in user database that allows individual users to have defined authentication (password) and login locations defined.

Further, if desired, a user can be configured as a read-only user, and Google Authenticator compatible two-factor authentication.

Internally, passwords are stored in the same way that OpenLDAP stores them by default, i.e. Salted SHA. Example, {SSHA}cca9bbffe6879f8367ab681952da2f995bf1668f

Configurable fields:

  • Username: the login of the user.

  • Password: The password of the user–please avoid using “:” as it may impact authentication.

  • Email: The email associated with given user, used for receiving Portal notifications about sessions.

  • Management Privilege: Defines what set of permissions is assigned to the user. One of:

    • None: users won't see any configurations, usually used with Portal user or Audit user option.
    • Admin: users will have admin rights, allowing them to perform tasks such as configuring settings, managing users, and accessing all resources.
    • Read Only: users will be unable to make any changes to the configuration, but they will retain access to resources based on their filter settings. Additionally, it will block access to management tabs, such as Users, Admin, Certificates, and various options like the 'Test Connection' button in the Data Sources tab.

  • Audit User: If enabled, users will have access to the Audit tab, where they can view and save records from the Audit Trail table, which logs all session operations within the portal.

  • Portal User: If enabled, users will have access to the Portal.

  • Authentication mode: Method to perform authentication by. One of:

    • Local/Secret: user will be authenticated by login & password. Credentials can be automatically fetched from Secrets Manager, if properly configured in Admin tab. More details in Secrets Manager for users
    • LDAP: user will be authenticated by LDAP server configured in Admin tab.
    • Kerberos: User will be authenticated by KDC server configured in Admin tab.

  • Two Factor Authentication: If enabled, it will present bar-code that can be scanned into the Google Authenticator software, and an account code, which can be used in place of the bar-code. This ID is in addition to the normal password authentication the user will be required to provide. Not available with Authentication mode: Kerberos.

Basic User (with Portal Mode enabled)

Require "Username", "Password" and Portal User enabled

Basic User (without Portal Mode enabled)

Require "Username", "Password" and selected Management Privilege

Kerberos user

Require "Username" and "Authentication mode: Kerberos"

More details about Kerberos Configuration here.

LDAP user

Require "Username" and "Authentication mode: LDAP"

More details about LDAP Configuration here.

If there is only one LDAP Configuration available, it will be used by default. Otherwise additional dropdown "LDAP Configuration" will appear to specify which config should be used with a particular user.

SAML2 user

Require "Username" and "Authenticate by: SAML2"

You can set up SAMl2 Configuration in the admin tab. (Manage section -> Admin tab -> SAML 2.0 Configuration Guide). SSO can be configured using saml2 auth with AWS IAM Identity Center, Okta, or other saml2 identity providers.

IAM user

Require "Username" and "Authenticate by: IAM"

When using IAM access, appropriate access to the IAM role should be configured for the management instance.

Secrets Manager for users

When Secrets Manager is configured, and Authentication mode: Local is selected, the users configuration shows a checkbox next to the password field. This option when enabled replaces the password input with Secret Name. After committing the changes application will automatically fetch the credentials residing under configured Secret Name and cache them. These will be used effectively as username and password values for this user.

For those utilizing a custom secrets manager, it is imperative to adhere to the structure outlined in AWS RDS secrets manager. For instance, the JSON format should resemble the following: {"username":"test","password":"test"}.

If there is more than one Secrets Manager Configuration available, additional "Secrets Manager" dropdown will appear next to Secret checkbox, to specify which config should be used with a particular user.

Note: This configuration currently does not support rotating credentials, that means that once we save a user, and values stored in Secrets Manager change, the heimdall user will still be using old values.

Groups

This feature is available for all Heimdall (GUI) users, doesn't mather whether user authenticates by LDAP or not.

This one allows to grant or revoke a group membership for testing purposes, e.g for LDAP based notifications (Notifications tab in admin tab).

For enhanced security measures, it is imperative that at least one real LDAP Group be extracted when utilizing this feature while using for LDAP authentication testing purposes.

What is important configuration applied there DOES NOT IMPACT the real groups membership on LDAP Server.