Authentication: Getting started
By default, user authentication is disabled and all actions are
performed under the special account named
The unique user has unrestricted access and does not require a password, so anyone can access the platform.
We strongly advise you to enable user authentication to secure the access to your data once Linkurious Enterprise is deployed on a server.
There are 2 possible authentication options:
- Local authentication: user accounts are managed within Linkurious Enterprise
- External authentication: user accounts are managed in a 3rd party application
Local authentication can be enabled from Linkurious Enterprise user interface.
Once local authentication is enabled, users need an account to access Linkurious Enterprise. Administrators can create accounts directly in Linkurious Enterprise (see how to create users).
To enable authentication use the Web user interface via the Admin > Users menu:
The following screen will be prompted if authentication is disabled. Click Enable Authentication.
Create an admin account and click Save and enable.
Passwords of local users are hashed with the PBKDF2 algorithm and the following parameters:
- iterations: 1000
- salt length: 96 bits
- key length: 256 bytes
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 inside Linkurious Enterprise.
Linkurious Enterprise supports the following external authentication services:
- 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 an Single-Sign-On (SSO) capable authentication service (OAuth/OpenID Connect or SAML2), your users won't need to login directly in Linkurious Enterprise but, instead, by clicking the SSO button they will be redirected to the identity provider for authentication.
If an external source already organizes users in groups, it's possible to use this information to map automatically
external groups to 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 we 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 Linkurious group names that you can use here are the following:
read(which corresponds to "Read and run queries" in the Web UI)
read and edit
read, edit and delete
Group names may or may not be case sensitive, that depends of the user-data-store vendor and collation.
For some identity providers the external group IDs is an actual name, for others is an ID:
- Azure AD uses the group ID, e.g.
- LDAP uses the content of the field configured in
- Microsoft Active Directory uses the group common name, e.g.
"Administrators"or the group distinguished name, e.g.
To exclude some groups of users from logging in into Linkurious, set up a list of
authorized groups in the configuration key
// 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 LKE user.
true makes an external user's groups
to be reset according to
externalUsersGroupMapping, each time the external user logs in.
// under the access configuration key// ..."autoRefreshGroupMapping": true// ...
Also, note that when
true updating external users' groups from within LKE is not allowed.
When using SSO to log 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
adminbuilt-in group is used, it will override the other groups.