Authentication: Getting started

When Linkurious Enterprise is started for the first time, authentication has to be set up so that users can access the platform.

There are 2 possible authentication options:

• Local authentication: user accounts are managed within Linkurious Enterprise
• External authentication: user accounts are managed via a 3rd party application

Local authentication

By default, when you access Linkurious Enterprise for the first time, you need to create a local administrator account, unless an external authentication provider has been configured and an external group is mapped into the admin group (see group mapping). In order to create this first admin account, you need to provide a valid license as a proof of ownership of your Linkurious Enterprise instance.

Once this local administrator account has been created, it can be used to connect to Linkurious Enterprise and create other user accounts (see how to create users).

Password hashing

Passwords of local users are hashed with the PBKDF2 algorithm and the following parameters:

• iterations: 1000
• salt length: 96 bits
• key length: 256 bytes

External authentication

When using an external source for authentication, users are automatically created in Linkurious Enterprise when they connect for the first time.

These shadow users allow to store specific data such as preferences, groups, and visualizations.

Passwords of external users are never stored within Linkurious Enterprise.

Authentication services

Linkurious Enterprise supports the following external authentication services:

• LDAP
• Microsoft Active Directory
• Microsoft Azure Active Directory
• Google Suite
• OpenID Connect
• SAML2 / ADFS

If your company uses an authentication service that Linkurious Enterprise does not support yet, please get in touch.

If you enable a Single-Sign-On (SSO) capable authentication service (OAuth/OpenID Connect or SAML2), your users don't need to sign in directly in Linkurious Enterprise. They instead sign in by clicking the SSO button and are then redirected to the identity provider for authentication.

Group mapping

If an external source already organizes users into groups, it's possible to use this information to automatically map external groups into Linkurious groups. To do so, you have to set the access.externalUsersGroupMapping configuration key to be an object with the external group IDs as keys and the internal group IDs, group names, or a combination of both as values (you can map both built-in and custom groups).

For example, if you want to provide group mapping for Microsoft Active Directory:

{ // under the access configuration key
  // ...
  "externalUsersGroupMapping": {
    "Administrators": 1 // any Active Directory admin is a Linkurious admin ("1" being the id of the admin built-in group)
    "DataAnalysts": "analyst" // any Active Directory data analyst will be assigned to the "analyst" custom group of each data source(s) containing a group with that name
    "ProductManagers": [3, "product manager"] // any Active Directory product manager will be assigned to the group with id "3" and to the "product manager" custom group of each data source(s) containing a group with that name
  }
  // ...
}

The built-in group names that you can use are the following:

• admin
• read only
• read (which corresponds to "Read and run queries" in the UI)
• read and edit
• read, edit and delete
• source manager

Group name case sensitivity depends on the user-data-store vendor and collation.

For some identity providers, the external group IDs are an actual name; for others, it is an ID:

• Azure AD uses the group ID, e.g. "818b6e03-15dd-4e19-8cb1-a4f434b40a04"
• LDAP uses the content of the field configured in access.ldap.groupField
• Microsoft Active Directory uses the group common name, e.g. "Administrators" or the group distinguished name, e.g. "CN=Administrators,CN=Users,DC=linkurious,DC=local"

To exclude some groups of users from signing in into Linkurious, set up a list of authorized groups in the configuration key access.externalUsersAllowedGroups.

{ // under the access configuration key
  // ...
  "externalUsersAllowedGroups": [
    "CN=Administrators,CN=Users,DC=linkurious,DC=local",
    "CN=Analysts,CN=Users,DC=linkurious,DC=local"
  ]
  // ...
}

By default, when an external user is connected for the first time, their external groups are mapped once. So any change in the user's group in the external source would not be reflected in the Linkurious Enterprise user. However, setting autoRefreshGroupMapping to true makes an external user's groups to be reset according to externalUsersGroupMapping, each time the external user signs in.

{ // under the access configuration key
  // ...
  "autoRefreshGroupMapping": true,
  // ...
}

Note that when autoRefreshGroupMapping is true updating external users' groups from within Linkurious Enterprise is not allowed.

When using SSO to sign in to Linkurious Enterprise, if the identity provider groups are mapped to more than one built-in group, Linkurious Enterprise will choose the one with the highest permissions per data-source and ignore the other groups. If admin built-in group is used, it will override the other groups.