Knowi provides a variety of powerful options on user rights, access management and external authentication methods for both internal usage and embedded usage modes.
Please contact your account manager for any questions on mapping out the permissions model to your own enterprise level permissions model.
We offer three types of roles by default: viewer, user and admin.
Viewers: Viewers are limited to consuming dashboards. While they can download data associated to widgets and run their own analysis on data they have access to, they cannot save or create their own dashboards. This role also cannot create any data assets, including datasources, queries, agents etc. In addition, they cannot invite or manage other users or groups.
Notice the menu structure on the left is limited.
Users: User roles can
Invite other users
Create and share dashboards, widgets, queries, datasources, agents
Create Email Reports
Create and manage Trigger Notifications
Create their own groups
Set Filters (dashboard or user level)
Example dashboard for a User level role. Note the menu options at the top of the dashboard, as well as on the left.
Admin Users: Admin get all rights to that of the user, plus the ability edit/modify other users and their associated rights.
Team management for an Admin viewer:
User groups are logical groupings of users that data related assets (dashboards, queries, datasources, agents) can be shared to. A user can belong to one or more groups.
Groups can be created and modified from the Team Management menu. Example:
Users can be added from the team menu:
Specify the email address, Role and associated Groups to the new user.
Add any optional user filters. User filters enable row level security to filter out data. Read more about User Level Filters.
If Two factor authentication is required, you can set it during the invite (or you can enable it later).
Invite the user. Once the user has accepted the invite, they?ll see all their data assets (dashboards, datasources, queries, agents) shared to them or their group.
Each user can customize their timezone and change passwords. Admin users can also edit user roles, groups, timezones and user filters for any other user.
This option allows Admin users to login into the application on behalf of any foreign user account that they have access to on the administration page. There is a number of restrictions that come along with that feature.
1. user must be authenticated 2. user must possess a role of ADMIN 3. user can use the feature only providing active customer account 4. user can NOT use the feature on behalf of a foreign account (in a chain)
The 'Login as this user' icon is supposed to be visible on the right hand action bar of the user list.
As soon as authentication is passed the informational banner is attached to the top of the page including basic information of the user account selected.
At any point in time you can release the user account and get back the the original one by clicking on the 'Release user' button, in such a way you will be redirected back to the user administration page.
For added security, admin users can enable Two factor Authentication, which will send an SMS code to the phone number on record for that user that they must enter before login.
All data assets (dashboards, queries, datasources, agents) are private to the user by default, unless shared to other users or groups. Furthermore, each asset can be configured for granular read or edit access at a group or an individual user level.
Dashboards can be shared to an specific user, or a group. In addition, you can specify if the user has View access or Edit. View access restricts the user to a view mode where they can consume the dashboard, analyze the data, apply temporary filters (for their session), download the data behind the visualizations but cannot make any changes to the dashboard.
A datasource, for example, a database connection can be shared to another user or group, with edit or consumption rights. With Edit, the user (or the group) will have access to modify the datasource (not common). With consumption only rights, the user can create new queries from the datasource, but will not be able to see or edit, or clone the datasource details.
You can add a query against source.
Setting permissions :
Consume vs Edit: The first datasource in the following screenshot is consume only (note the actions that can be performed on the right) vs. full edit privileges on the other datasource.
Queries can be shared with Edit or View only rights to groups and/or users. Edit rights enable collaboration on the same query by multiple users and includes edit, clone and delete rights for that query. A query shared with view only rights can be executed and cloned to create a user?s own version of the query.
Consume vs. Edit rights: The first query in the screenshot below is consume only, the second has edit rights.
A user can belong to one or more groups, and marked with either consumption or publish rights for the specific group. In consumption mode, the user has read access to assets shared, but cannot publish into the same group. This allows publishing of assets from one user into a group, but does not allow the consumer to publish it back into the parent group.
Example: Let's say an "engineering" group writes and publishes baseline queries to an analyst and wants to maintain the original queries and does not want that user to publish queries back to the engineering group. This can be done by setting the rights during the user invite. The analyst can publish it to their own groups, but cannot post back to the parent group.
Assigning user-group consume/edit rights:
There may be cases when any asset that the user creates needs be automatically shared to other groups, instead of sharing a specific asset explicitly (query etc.). In such cases, you can apply an 'Automatic Share to Group' setting that will automatically publish any assets created by the user to those groups that can be used by other users. This is available during user creation as well as within the edit menu.
User filters can be set that limits the data returned to the user across all their dashboards. There are two modes:
Query Parameters: Helps you define query parameters that can be passed in all the way into direct queries against your datasource. These parameters can be set at the user level and replaced during query execution.
Filter on Query Results: This post processes the data returned any any query to filter by the parameters set.
For an in-depth look at content filters, see section on Filters & Query Parameters.
You can setup connection with an LDAP server to allow your users to login into knowi using LDAP credentials. Please Contact us to enable this feature. LDAP server used only as read-only information to login and get info about logged-in user objects to map to Knowi fields of user account.
You as administrator of your account will be able to see LDAP tab with configurations in User settings. You can create multiple different LDAP configurations. Click "Add" to add new configuration. If you want to edit an existing configuration, please select it from drop-down list. After selecting you can edit or view existing configuration or delete it by pressing "Delete" button.
Type an configuration name (any), your LDAP server host and port, and select TLS checkbox if your LDAP server supports TLS encryption.
This section used to enter an "master" LDAP account which have access to get info about LDAP user objects which you or users want to login with. After entering credentials you can click small "Test" button to check if credentials and Connection details valid. This will run connection with LDAP server, "bind" with entered master DN and then unbind and disconnect from server.
Fill fields to search user through LDAP:
Base search DN: this is the top root path to start search of user from.
Login attributes: list comma-separated attribute names of user objects which will be used as login field to login into Knowi. E.g. this could be "uid", "cn" and etc. System will choose first match via any of the provided attributes (OR filter will be used to search users with this attributes).
Email attribute: this field will be used to read email attribute and assign to email field of Knowi User.
User Name Attributes: this field is list of attributes to set to Knowi User Name, commonly this is First Name and User Name.
ID attribute: important field as this should uniquely identify your user in LDAP server.
Filter (optional): this is optional filter field used to filter search through user objects for login. E.g. can filter by groups, organisations and etc. Please refer LDAP server documentation on filter syntax.
Please choose which Knowi role will be map to LDAP user when login into Knowi. Use drop-down to select it. Optionally select Default Groups which will be set to user. If you will change any of this settings, LDAP users will get it on next login into Knowi.
After saving newly created LDAP configuration, you will get LDAP login URL. This is url which your LDAP users should use to login into Knowi.
At bottom of LDAP configuration press "Test login" button and you will be presented with login dialog box. Type in login attribute values to login with an LDAP account and press Test. This will do all login sequence by searching user via attributes and binding it if possible. If password is not entered (it is optional), user will be just found using master LDAP account and not binded with password.
This section usefull if you want to test if all LDAP configuration fields valid. After pressing Test button you will see log output showing exact steps made by the system to connect to LDAP.
You provide link to login with LDAP to Knowi to your users. This link you got from step of LDAP configuration creation in Knowi user settings. This link is associated with your customer account and your exact LDAP configuration. When user navigate with this link, it will be presented with special login window. In "ID" field user should enter an login attribute value (corresponding to login attribute in your LDAP server). In password user should type his user LDAP password. After LOGIN user will be entered into knowi using LDAP credentials.
If this is first-time user with such ID (the ID is setup in LDAP configuration page) then this user will be automatically created as new user in Knowi. If this is repeating user login, then will be used existing Knowi user account. In this case all changed fields, roles and groups will be updated from LDAP server into Knowi user account. E.g. if user name in LDAP server was changed, this will be updated in Knowi at login stage.