Entitlements and permissions
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.
First set up two new user groups:
kxUserSupport. The Users will have access to the KX Dashboards. The support team will have access to the same dashboards, plus the ability to interrogate and restart the service classes via KX Control.
Secondly we must set up two new entity groups:
kxDashboards group will contain permissions to the dashboard. The
kxServices group will contain permissions which allow access to the service classes.
|name||of an||that contains|
||entity group||the dashboard|
||entity group||the service classes|
||user group||entity groups to view and access the dashboard|
||user group||entity groups to view and access the dashboard and service classes|
Create entity groups
kxWarehouse package and select New > Entity Group from the context menu. Enter the name kxDashboards and click Add
Add the MemBucket dashboard, API.monPublic analytic group and .monPublic.getMem , .monPublic.getMemBucket analytics to the associated entities. Click Save.
kxWarehouse package and select New > Entity Group from the context menu. Enter the name kxServices and click Add
Add the kxw service classes created previously to the associated entities. Click Save.
Create the users
kxWarehouse package and select New > User from the context menu. Enter the name kxUser and click Add. User is kxUser, password can be
12345678 or a password of your choice. A fake email input for now is ok. Save it.
Now repeat this process for a kxSupport.
Create the user groups
kxWarehouse package and select New > User Group from the context menu.
Give the user group the name kxUsers and click Add.
In the User Group Contents subtab, select
kxUser and add it to the group members.
In the Entity Permissions tab, add the entity group
kxDashboards to the selected entities and set the access level to Read.
Save the user group.
Repeat the steps above but for the following information:
Create a new user group called
kxSupportto the users in the group.
kxUserSupportgroup read/write access on both the
UxRuntimeread permissions to allow Control UI access.
Log into KX Control and KX Dashboards as the
kxSupportuser. From Control it should be possible to start and stop the listed service classes, but not others. The support user should be able to edit the dashboard.
Next log in as the _
kxUseraccount should only be able to view the dashboard, not edit it nor be able to control edit anything in Control UI.
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.