- On a high-level, the permissions are divided into two parts:
- Authentication Setups
- Authentication based on integrated user repository
When a user logs in, the application will connect onto the database and validate the user credentials based on
On success, it will retrieve the users usergroup.
All actions from that user will then be executed by impersonating the into the corresponding usergroup.
- Authentication based on Database Authentication (and possibly AD)
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 the into the corresponding usergroup
- Application-Level User Groups
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.
- 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 Authentification via Database
If the processing database supports AD authentification via Kerberos, users can be created to use this mechanism. This process has currently been tested to work with MSSQL. First you 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 callled
CLIENT_DB_CONNECTIONSTRING_USER_AUTHENTICATIONhas to be defined, that has integrated security and kerberos enabled. (e.g.
integratedSecurity=true;authenticationScheme=JavaKerberos;) This 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_dbset and a username in the form of
email@example.com(the same as you can use to authenticate in your Windows Domain)
- Some remarks:
The old NTLM form like ‘DOMAINusername’ is not supported
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 => 'firstname.lastname@example.org', email => 'email@example.com', full_name => 'John Doe', pg_user => 'dvb_user', -- this is the default and can be ommited authenticate_on_client_db = true );
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_userdefined role, not the user himself/herself.