Role Concept
On a high-level, the permissions are divided into two parts:
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: 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
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. |
User Management
Management of users is done through the command line interface. Please check the knowledge base article for available actions. (kb.datavault-builder.com)
Authentication
- Authentication based on integrated user repository
Process
When a user logs in, the application will connect onto the database and validate the user credentials based on
dvb_config.auth_users
table.On success, it will retrieve the users usergroup.
All actions from that user will then be executed by impersonating into the corresponding usergroup.
- Authentication based on Database Authentication (and possibly AD)
Process
When a user logs in, the application try to connect onto the database using the provided credentials.
The database validates the credentials directly or by calling a connected AD.
On success, based on the application repository in
dvb_config.auth_users
, the corresponding group of the user is read.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 Kerberosmy.username@mydomain.tld
(the same as you can use to authenticate in your Windows Domain) - for NTLMmy.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 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.
- 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.