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 or JDBC connection

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

• Hostname or IP address: One of

  • IPv4 IP address in the format defined here
  • IPv6 IP address in the format defined here
  • Subnet address defined with either an IPv4 or IPv6 network address plus “/” and the subnet size
  • A DNS hostname that resolves to one or more IPv4 or IPv6 addresses. If more than one is provided, than any resolved IP is allowed.
  • In the event no users are defined, than unrestricted access is allowed
  • If no hostnames or IPs are provided for a given user, then the user is provided unrestricted access from any network

• Admin: If enabled, users will have admin rights, allowing them to perform tasks such as configuring settings, managing users, and accessing all resources.

• Read Only User: If enabled, 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.

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

• 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.

• Authenticate By LDAP: If enabled, user will be authenticated by LDAP server configured in Admin tab.

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 "Authenticate by Kerberos"

You can set up Kerberos Configuration in the admin tab. (Manage section -> Admin tab -> Kerberos Configuration)

LDAP user

Require "Username" and "Authenticate by LDAP"

You can set up LDAP Configuration in the admin tab. (Manage section -> Admin tab -> LDAP Configuration)

AWS Secrets Manager for users

On AWS environment 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"}.

Note: This configuration currently does not support rotating credentials, that means that once we save a user, and values stored in AWS 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.