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.






 

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:

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.