Attention

This document is no longer being updated. For the most recent documentation, including the latest release notes for version 6, please refer to Documentation Version 7

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.

Authentication Setups
  1. Authentication based on integrated user repository
    ../_images/authenticationUser.png

    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.

  2. Authentication based on Database Authentication (and possibly AD)
    ../_images/authenticationDB.png

    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.

Application-Level User Groups

Usergroup

Permissions

Purpose

dvb_admin

Non-Restricted Permissions

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

dvb_user

All permissions except user administration and application patching

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

dvb_user_readonly

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.

dvb_operations

Permission to only use loading-related APIS

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

When creating a user, the following settings are available:

  • Non-Expiring Tokens: Once the user has been successfully authenticated, he can login with the retrieved token indefinitely. This is often used for technical users and is not recommended for regular users!

  • Authenticate against client database: When logging in, the user will be authenticated with a login on the client database as well. This way, login can also be removed by revoking the login of the user from database. If the database supports AD-Authentication, this way an integration with an AD can be achieved (see the paragraph below).

User Management

Management of users is done through the command line interface. In that section the related operations on the command line are listed.

active directory auth Active Directory Authentification via Database

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 Operations -> 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 6.6.0.0+
);

Hint

Setting a password here is not permitted.

Note

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.

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.