USER INTERFACE OVERVIEW
The Device Portal undergoes real-time updates in response to user selections within the left-hand side tree menu. The primary interface, the Dashboard, provides administrators with a comprehensive overview, including information on the number of online devices, active admin sessions, and the total count of online users.
Note: Please feel free to provide feedback regarding the design and positioning of features within the Portal. If you encounter any issues or areas of frustration, kindly share your feedback, and we will consider incorporating your suggestions in upcoming releases.
ADMINISTRATOR PERMISSION MODEL
Introduction
The On-Prem Thinscale Device Portal typically uses a hierarchical data structure to navigate many tree views to find the appropriate data. The permission model employed to manage the data was also hierarchical. However, this inheritance-based approach has lost favor due to its inflexibility, rigidity, and potential for unintended consequences.
One of the first decisions that Thinscale performed when developing the Device Portal within Thinscale Cloud was to examine the data model that should be used. It was decided to use a flat data structure, allowing data to be navigated via search queries that can be saved as views.
Flat data structures are generally simple, flexible, efficient, and easy to maintain. They are ideal for web applications requiring fast data access and frequent updates.
Based on the decision to employ a flat data structure, the Device Portal embraces a flat permission model, allowing for direct permissions configuration across all entities within an Admin Resource Group. This approach offers exceptional flexibility and granularity, with the ability to assign multiple roles and permission sets. Permission reports are also available to assess the permissions of every administrator for each entity in the system.
While understanding this model may require a learning curve, it ultimately provides a highly flexible and manageable permission system, affording greater control and adaptability. This document aims to help explain the administrator permission model and the terminology used and to help understand the reasoning behind the design.
The Administrator permission model is made up of the following entities:
| TERM | DESCRIPTION |
| Admin Users |
Note: Local Admin User accounts are only recommended for initial commissioning, proof of concept, and evaluation purposes. It is not recommended to leave Local User accounts enabled on the system. For security reasons, it is highly recommended to authenticate and authorize administrators via an Auth Provider.
|
| Admin Users Groups |
Admin User Groups are used to group sets of Administrators on the system. Local Admin Users can be manually added to the Admin User Group or using Auth Provider Groups Identifiers groups of administrators from groups within your Auth Provider can be identified and added easily to the Admin User Group. The permissions model on the Device Portal will ultimately use Admin User Groups to identify the administrators that receive the appropriate permissions (via Admin Roles). |
| Admin Roles |
Note: An Admin User can exist in several Admin User Groups, and each Admin User Group could have several roles assigned to it. This allows great flexibility when configuring permissions as an Admin User or Admin User Group could be assigned multiple roles.
|
| Admin Permission Sets |
An Admin Permission Set is a set of permissions associated with data types in the system. Typical permissions include List, Read, Update, Add, and Delete, although for Actions and Reports, the consent is simply ‘Allowed.’ For some data types (e.g., Organisation), the permissions operate globally for all entities of that type; however, for most entities on the system, permission is applied to a set of entities, e.g., Read Devices might be limited to a set of Devices in a specific region. The full settings associated with Admin Permission Sets are shown in the screenshot below. As part of an Admin Role configuration, the Admin Permission Set is associated with a set of resources in an Admin Resource Group that limits the scope of the permissions to the set of resources. |
| Admin Resource Folders |
Note: An Admin Resource Folder can be included in many Admin Resource Groups to allow for highly flexible permissions to be assigned via Admin Roles. To allow for the most excellent flexibility, entities with the smallest commonality (e.g., the smallest business unit with the smallest region) should be added to Admin Resource Folders.
|
| Admin Resource Groups |
Admin Resource Groups are groups of Admin Resource Folders, which essentially makes them groups of entities. They are used to limit the permissions on an entity type to a set of specific entities in the Admin Role configuration. While Admin Resource Folders are typically a collection of entities with the smallest amount of commonality, Admin Resource Groups should be groupings of Admin Resource Folders that make more sense from the perspective of configuring permissions. Because the same Admin Resource Folders can be configured in multiple Admin Resource Groups, it is possible to have Admin Resource Groups that may include all the entities in a region and other Admin Resource Groups that may consist of all the entities globally for a business unit. |
Table 1: Description of the terminology and entity types of the permission model
The relationships between the entity types discussed above are visualized in the diagram below. Admin Roles to assign permissions (Admin Permission Sets) to a set of resources/entities (Admin Resource Groups/Folders) for a set of Admin Users as defined in the Admin User Group.
Figure 1: The relationships between the entity types of the permission model
ACCUMULATED PERMISSIONS
Allow Permissions Sets
For allow permission sets, the setting of permissions on a resource is accumulative. This means that all administrators start with no permissions on any entity. The permissions are calculated for the administrator by checking every “Allow” Permission Set in every Admin Role that the administrator is affiliated with and setting all appropriate permissions on all resources in the resource group.
If a consent is unchecked, the permission is simply not set for that permission set. The following permission set may grant the permission.
The example below sets the permissions for a “Standard Admin.” You can see that they get complete configuration, device management, and reporting permissions for the associated resources in the Admin Role (e.g., USA Resources). They would not get any organization permissions.
Figure 2: Configuration of a “Standard Admin” Permission Set
Deny Permissions Sets
Deny Permission sets are used to Deny permission on a set of entities for an administrator. Once permission is denied, it can never be allowed again via an allow (or any) permission set. The only way to grant the consent again is to disassociate the Deny Permission Set from the administrator.
A typical example of using a Deny Permission Set would be to deny Reading, Addling, Updating, or Deleting Security Profiles on All Resources. This configuration could be added to a normal “Regional Admin Role” to prevent regional administrators from accessing the Security Profiles. Alternatively, this could have been accomplished by ensuring that the Security Profile permissions for Read, Add, Update, and Delete were not set on any Permission Set associated with the administrator.
Figure 3: An example of a Deny Permission Set being used to protect access to Security Profiles
The Deny Security Profiles permission set configured above could be used to protect Security Profiles in the configuration of an Admin Role. Consider the example below where an Admin Role is configured to protect the Security Profiles by using a Deny permission set against all resources in the system.
Figure 4: Example configuration of an Admin Role “USA Regional Admin” protecting the Security Profiles by using a Deny permission set against all resources in the system.
As said above, the deny permission set would be unnecessary if the Read, Add, Update, and Delete permissions for the Security Profile were removed from the Standard Admin permission Set. In this case, the permissions would have never been set so that they would be in the Not Allowed state. The Deny permission set is a comfort factor because it cannot be accidentally granted via another permission set.
Order of Admin Permission Sets or Admin Roles
With the calculation of permissions as described above, the order of Admin Permission Sets in an Admin Role (or the order of Admin Roles associated with an Admin User Group) does NOT matter.
Why does an Admin Role allow multiple Admin Permission Sets and Admin Resource Groups?
Multiple pairs of Admin Permission Sets and Admin Resource Groups allow different sets of permissions to be applied to different sets of resources. For example, an administrator may need many permissions on a particular set of resources but much fewer permissions (List or Read, perhaps) on other resources. Three typical uses for this are:
(1) The Deny Permission set the example that we saw above where the Deny Permission Set example is used to restrict access to sensitive entities.
(2) Adding the “Allow List/Select Entities” permission set on all the resources in a “Shared” Admin Resource Group. This would allow administrators to share the entities they are responsible for, knowing they cannot be edited or deleted.
(3) Setting up the main permissions for a role via a single pair of Admin Permission Sets and Admin Resource Groups and then configuring additional pairs of very specific Admin Permission Sets and Admin Resource Groups to add slightly different exceptions to the basic configuration. i.e., Grant Update right for a Device Policy to a small set of administrators as an extra right.
Why Admin Resource Groups and Admin Resource Folders?
Ultimately, the management of administrator permissions will be based on the resources in Admin Resource Groups; however, the Admin Resource Folders are used to add flexibility to manage these permissions.
It is recommended to use Admin Resource Folders as the most minor collection of resources with the same permissions. Typically, this would be a business unit and region. These Admin Resource Folders can then be combined to form Admin Resource Groups. Admin Resource Folders can be in many Admin Resource Groups, offering excellent flexibility.
It is best to illustrate the above by example. Consider the use case where several business units are being managed across different regions (in this case, global continents). The day-to-day administration of the entities may be managed by “Regional Administrators,” who will need various permissions for reading, adding, updating, and deleting all the different resources in the region. Typically, a regional administrator may be responsible for all the business units but only for that geographical region. Alternatively, each business unit may have an “Account Manager” responsible for reporting on the status of each business unit. They may need their permission set for all the parts of the business unit across the different regions.
Figure 5: Example use of Admin Resource Folders and Admin Resource Groups to allow permissions to be easily configured for Regional Administrator and Account Manager roles.
Permissions and Types of Data
The management of data will vary depending on the needs of the organization. The following example considers three different types of data that need to be managed differently by the organization.
Regional Data
Regional Administrators manage the data. The data is not typically shared with other regions. Data may be specific to a customer or shared with many customers within the area.
Typical examples of this type of data include:
• Device Groups
• Config Assignments
• Device Profiles (including UI Profile, General Profile, MDM Profile)
• Device Policy
• Software Package Groups
Shared / Global Data
A global configuration of the entity is sufficient for most Regions / Customers. Regional Admins manage and share the entities (Shared Folder).
Typical examples of this type of data include:
• TDA Update Policy
• Software Packages
• Device Analytics Profile
In this case, a single Admin Resource Folder called “Shared Folder” could be set up and added to each regional Admin Resource Group so that the administrator gets the same permissions for the shared resources as the normal regional resources.
Alternatively, the “Shared Folder” could be added to an Admin Resource Group called “Shared Group.” Permissions could then be added by applying permissions specifically to this group.
In more complex situations, shared access may be limited, and many shared folders and groups may need to be set up to customize the permissions.
Protected Data
The data needs to be protected from most Admins. Specialist Admins manage and share the entities (Protected Folder). Regional Admins will get “List” or “Read” access.
Typical examples of this type of data include:
• Auth Providers
• Security Profiles
In this case, a single Admin Resource Folder called “Protected Folder” could be configured and added to an Admin Resource Group called “Protected Group.” Permissions could then be granted to the group to give full read/write permission to a select few and “list only” permissions to the majority of administrators.
Side Bar Navigation Buttons
Organisation
Organisation Settings
In this section of the Device Portal, you will find three distinctive sections:
Local Administrator Accounts
Authentication Providers
Device Analytics
Local administrator accounts are required for the initial configuration of Auth Providers on the System. It is recommended to disable local accounts once the Auth Providers have been successfully configured.
Warn if local Administrator accounts are left enabled if enabled every time an administrator with permission to add an Auth Provider on the system logs in, they will be met with a warning to disable local administrator accounts.
Auth Providers
This feature lets the user choose the Authentication Provider to access the Device Portal.
Admin Roles
Admin Roles are used to configure the permissions for administrators on the Device Portal. The "Super Admin Roles" feature encompasses all permissions associated with resources within the Device Portal.
This option is a default setting and is not removable.
Admin user groups represent ALL the groups of users that, once added, will receive the permission set in the Super Admin role.
Admin Permissions Set
The Device Portal will be presented with four default permissions set by default. Those sets cannot be modified; they need to be removed.
However, the easiest way of modifying an existing set is to duplicate the one you want to enhance or modify.
Each role is associated with a distinct set of permissions applied to various resource groups and folders.
It is important to note that you can create multiple permission sets with varying levels of granularity and visibility. These permissions are managed through checkboxes and are categorized into five groups:
Allow or Deny Permission Set
Allow permission sets allow permissions from different Permission Sets to accumulate on additional resources. A 'Deny' permission set prevents specific permissions on resources. An allowed permission can never overwrite a denied permission.
Global Organisation Permissions
These permissions operate globally across the entire system and are not limited to the resources of the appropriate resource group.
Config Admin Permissions
These permissions operate on the configuration level and can be used to granularly allow or deny access just to a specific resource folder, device, or configuration.
Device Management Permissions
These permissions control if any device actions like Shutdown, Restart, or Refresh profile are allowed.
Report Permissions
These permissions operate globally across the entire system and are not limited to the resources of the appropriate resource group. You can either allow visibility of the Audit and Permission reports or not.
Admin Resource Group
The Admin Resource group shows all the Resource Folders created in the Device Portal.
Admin Resource Folder
The admin resource folders denote the designated location for assigning configuration options such as Devices and Device Groups, Profile Configuration settings, Authentication providers, Device Policies, and other related entities.
You can also add tags to a resource folder.
“Search Tags” are the parameters of value pairs that enable you to categorize resources. Search Tags and Values are case-insensitive and limited to 256 characters.
Admin User Groups
The Admin User group tab represents the list of the Users having different permissions on different resources. i.e., Super Admin = Group for an administrator with full permissions on all resources
Admin Users
The Admin Users Tab shows the list of all Users, local or connected via an Authentication Provider that logged in to the Device Portal.