Skip to content

Entitlements and users

Entitlements restrict what users can see and what they can access. For example, a user may be able to see a process, but not be allowed to access functions or data inside that process. This is done by creating different entity groups and user groups and assigning permissions to those groups. Entitlements are defined using entity groups, entities, user groups, users and access levels

Entity Groups : Containers for entities that you want to permission together. These groups can also be nested, which allows you to layer permissions.

Entities : The parts that make up your system (e.g. instances, tasks, connections, etc). They appear in their folders where created, but will also appear automatically in the Entities folder under Entitlements so are available for permissioning.

User Groups : Containers for users that you want to permission together. User groups can set permissions on seeing or accessing individual entities, entity groups, or administrator APIs (add, edit, delete entities).

Users : Users are individuals who use the system in some capacity. Kx Control can be connected to LDAP to authenticate users and download user group memberships.

Access Levels : Each entity has four access levels (Read, Read/Write, Read/Deny Write, Deny All). A user can inherit different access levels from groups they belong to. For each user, the entitlements are resolved to give a true/false value for each entity. A Deny permission overrides all others and takes precedence. That’s why there is an explicit difference between Read and Read/Deny Write access levels.

Entitlements provide a flexible and granular way of permissioning the system, but can be challenging to set up. Grouping and permissioning correctly can be difficult because of the permutations and combinations that can occur when entity groups and user groups overlap. The simplest approach is to break the permissioning problem down into chunks which make adding and modifying permissions straightforward.

User groups

First set up two new user groups: dhtTraders and dhtTraderSupport. The traders will have access to the trading dashboard. The support team will have access to the trading dashboards, plus the ability to interrogate and restart the processes via Kx Control.

name of an that contains
dhtTradingDashboards entity group the dashboard
dhtTradingProcesses entity group the process tasks
dhtTraders user group entity groups to view and access the dashboard
dhtTraderSupport user group entity groups to view and access the dashboard and processes

This approach will provide key advantages. For example, there may be managers who need to see trading dashboards and management dashboards. In that case, create a new a new entity group dhtManagementDashboards and a new user group dhtTradingManagers, then permission dhtTradingManagers to inherit both dhtTradingDashboards and dhtManagementDashboards.

Create entity groups

Right-click on dhtPackage and select New > Entity Group from the context menu. Enter the name dhtTradingDashboards and click Add


Add the dhtDashboard dashboard to the associated entities. Click Save.


Right-click on dhtPackage and select New > Entity Group from the context menu. Enter the name dhtTradingProcesses and click Add.


Add the dht tasks to the associated entities.


Add the dht process instances to the associated entities.


Add the dht workflow to theassociated entities.


In the end these entities should be added. Save the entity group.


Create the users

Create two users, one for traders and one for support.

Right-click on dhtPackage and select New > User from the context menu. In the dialog, enter the following information and click Add. User is dhtTrader, password can be 12345678 or a password of choice. A fake email address for now is ok. Save it.


Create another user named dhtSupport, password can be 12345678 or a password of choice. A fake email address for now is ok. Save it.

Create the user groups

Right click on dhtPackage and select New > User Group from the context menu.

Give the user group the name dhtTraders and click Add. Then Save the user group.


In the User Group Contents subtab, select dhtTrader and add it to the group members.


In the Entity Permissions tab, add the entity group dhtTradingDashboards to the selected entities and set the access level to Read.


Save the user group.

Repeat the steps above but for the following information.

  1. Create a new user group called dhtTraderSupport.
  2. Add dhtSupport to the users in the group.
  3. Give the dhtTraderSupport group read/write access on both the dhtTradingDashboards and dhtTradingProcesses entity groups.
  4. Add UxProcess and UxRuntime read permissions to allow Control UI access.
  5. Test. Log into Kx Control and Kx Dashboards. From Control it should be possible to start and stop the listed processes, but not others. The support user should be able to edit the dashboard.
  6. Test. The dhtTrader account should only be able to view the dashboard, not edit it nor be able to control edit anything in Control UI.
  7. Test the system to ensure users can do all the things they are permissioned for, and cannot do things for which they are not permissioned for. This test will be required for both Kx Control and 0 access.


    While having permissions to access the tasks would seem sufficient for a support role, access to the instances and the workflow allow them to see the tasks in the process viewer and use the workflow editor to start and stop the entire workflow.

    This is fine for everything requiring direct interaction with Control. For example, there is no way for an unpermissioned user to connect to Control and change the definition of an analytic. However, the processes themselves are still unrestricted. An unpermissioned user could connect directly to the RDB, without supplying a user name and password, and run a query. To lock down processes, turn on permissioning. This is done by the Permissioned reserved parameter.

    It’s probably a good idea to set No Client System Calls to yes as well, as this restricts the user from accessing the file system of the machine from the process. Warning that if you turn this on, the IDE requires some system calls and so you will not be able to connect to this process.

    This tutorial does not cover the intricacies of a properly permissioned platform install, just an example of a couple of roles.

  8. Make the Permissioned change on the RDB. For the change to take effect, the process will have to be restarted. Now no user can access the RDB without supplying a correct user name and password.


Open up dhtDashboard.

The connection created to connect to the RDB doesn’t specify a username and password and is being rejected.

The dashboard entitlements work in two steps. A single user is used to connect to the process running at the back end. This user must have permission to access this process. Then, when running the query, the permissions of the user who has logged into the dashboard are used – so the supplied user must have the ability to access the required functions/data.

The first step to resolution is to create a system user which will allow dashboards to connect to Kx Platform processes.

  1. Create a dhtSystem user group, and one member of that group, dhtDash.
  2. Give the dhtSystem user group read access to the dhtTradingProcesses entity group.
  3. Make the dhtDash user a member of the Administrators group – all dashboard connections have to be administrators to run correctly queries that inherit the logged in users credentials.
  4. In Kx Control, update the dhtRDBConnection connection to use the new dhtDash user name and password.

Viewing the dashboard for dhtTrader should work again after these changes.