Role Concept

On a high-level, the permissions are divided into two parts:

application level

Application-Level: The Datavault Builder has a set of predefined roles, to which a user can be assigned. This mainly limits the API-usage.

processing database

Processing Database: The permissions are based on the users permissions on database level. This limits the actual actions the user can perform on the database.

Application-Level User Groups





Non-Restricted Permissions

Used for the setup and configuration of the application. Can administer other users; Can patch the application if needed.


All permissions except user administration and application patching

Used for the data modeller. Can make use of all APIs.


Permission to use only reading APIs

Used for business users to access the documentation and analyze the source of the data presented in the data mart.


Permission to only use loading-related APIS

Used for operational user or 3rd party application, which can trigger and monitor loading processes.

User Management

Management of users is done through the command line interface. Please check the knowledge base article for available actions. (


  • Authentication based on integrated user repository


    1. When a user logs in, the application will connect onto the database and validate the user credentials based on dvb_config.auth_users table.

    2. On success, it will retrieve the users usergroup.

    3. All actions from that user will then be executed by impersonating into the corresponding usergroup.

  • Authentication based on Database Authentication (and possibly AD)


    1. When a user logs in, the application try to connect onto the database using the provided credentials.

    2. The database validates the credentials directly or by calling a connected AD.

    3. On success, based on the application repository in dvb_config.auth_users, the corresponding group of the user is read.

    4. All actions from that user will then be executed by impersonating into the corresponding usergroup.

    Setup using AD

    If the processing database supports AD authentification via Kerberos or NTLM, users can be created to use this mechanism. This process has currently been tested to work with MSSQL. For Kerberos authentication, you first have to assure that the the Docker stack has the DNS entries of the domain and is not prohibited to access the Kerberos Distribution Center (usually the Domain Controllers) by some firewall rules.

    For MSSQL, in the docker-compose core configuration, a seperate environment variable called CLIENT_DB_CONNECTIONSTRING_USER_AUTHENTICATION has to be defined, that has integrated security and kerberos or NTLM enabled.

    • for Kerberos: jdbc:sqlserver://<mssql_host>:1433;databaseName=datavaultbuilder;integratedSecurity=true;authenticationScheme=JavaKerberos;

    • for NTLM: jdbc:sqlserver://<mssql_host>:1433;databaseName=datavaultbuilder;integratedSecurity=true;authenticationScheme=NTLM;domain=<youdomain>;

    This connection string is only used during login to authorize the user.

    Then, each users allowed to login into Datavault Builder must be created with the flag authenticate_on_client_db set and a username in the form of - for Kerberos my.username@mydomain.tld (the same as you can use to authenticate in your Windows Domain) - for NTLM my.username (without domain! it only works if the domain is defined in the connection string above)

    Some remarks:
    • For Kerberos you may configure the krb5.conf and map it into the connection_pool container

    • The ‘mydomain.tld’ part is technically a Kerberos Realm - but here it is case insensitive

    An example to create such a user in command line:

    SELECT dvb_core.f_create_user(
      username => '[email protected]',
      email => '[email protected]',
      full_name => 'John Doe',
      pg_user => 'dvb_user', -- this is the default and can be ommited
      authenticate_on_client_db => true,
      your_current_password => '***' -- only required from


    Setting a password here is not permitted.


    Be aware that the user is authenticated on the active directory only during login - all subsequent DB calls are done as technical users with a role change to the as pg_user defined role, not the user himself/herself.

  • Authentication based on AD Authentication

    We do support direct integration with Azure AD. Please check our knowledge base on the detailed configuration steps.

Role Concept Limitations

  • Due to database side limitations, when using Snowflake or Oracle as a processing database, only application level (e.g. API) privileges are applied. The impersonation on the database level is disabled and all actions are always performed as the technical user/role.