Data Access¶
Data security in the system is achieved by data partitioning and user roles.
With data partitioning, the system ensures that administrative users who access the system can only view and perform operations on instances of entities that are provisioned at their parent hierarchy, in other words at the same hierarchy level as they are, or at sub-trees of that hierarchy. The system restricts access to resources based on user’s parent hierarchy and this restriction is enforced in API middleware for every operation that is requested. This partitioning is enforced across the various system interfaces, for example loaders, API, and the Admin Portal.
This for example ensures that an administrator for “VS-Corp” cannot view or affect data in customer “GenCorp” within the system. The “VS-Corp” administrator can only see and affect entities assigned to “VS-Corp” or lower, for example Boston, Brooklyn, Chicago and New York in the above diagram.
Note
When an administrator navigates to a particular hierarchy and views a list of model instances, there may be instances visible that were created at a higher level. For example, a Provider administrator’s view of the list of menu layouts may show instances created above the Provider’s hierarchy.
This visibility is for example required so that a Field Display Policy can be cloned at a lower level. It does not alter a user’s modify permissions on model instances created at higher hierarchies. Conversely, a Provider administrator who inspects the list at a hierarchy level below the provider level will still be able to modify instances created at the provider’s hierarchy.
(A setting Visible at Lower Hierarchy is enabled when the model is designed. It is available for Data, Domain, and Relation definitions. For Relations, the setting overrides the setting in any related models. Refer to the table below.)
A user’s role defines, via an access profile, the fine-grained permissions to the specific entities that the user can see and how the user can interact with these. The permissions include details of each entity type in the system, as well as the relevant privileges related to that entity type. For further details on user roles and access profiles, refer to Role Based Access.
From data partitioning, the hierarchy will determine the specific instances of the various entities that the user can interact with; while the role and access profile assigned to the user determines the permitted operations that can be performed on these instances.
The table below shows the list of models with the setting Visible at Lower Hierarchy set to true:
| Name | Model Type |
|---|---|
| AccessProfile | data/DataModel |
| Adaptation | data/DataModel |
| AdaptationLog | data/DataModel |
| BulkAdminDataRefreshPerHierarchy | data/DataModel |
| BulkAdminFullDataRefresh | data/DataModel |
| BulkAdminScheduleDataRefresh | data/DataModel |
| Bundle | data/DataModel |
| Bundle | data/Relation |
| ConfigurationTemplate | data/DataModel |
| Countries | data/DataModel |
| CredentialPolicy | data/DataModel |
| FeatureConfigProfile | data/DataModel |
| FieldDisplayPolicy | data/DataModel |
| HcsCommandBuilderDAT | data/DataModel |
| HcsDeviceGroupDAT | data/DataModel |
| HcsDeviceTypeDAT | data/DataModel |
| HcsDpDialPlanSchemaDAT | data/DataModel |
| HcsDpDialPlanSchemaGroupDAT | data/DataModel |
| HcsLocalizedStringDat | data/DataModel |
| HcsMovePhoneCustomizationsDAT | data/DataModel |
| HcsMoveSubCustomizationsDAT | data/DataModel |
| HcsPrimeCollabREL | data/Relation |
| LandingPage | data/DataModel |
| Macro | data/DataModel |
| MenuLayout | data/DataModel |
| Patch | data/DataModel |
| ProvisioningWorkflow | data/DataModel |
| QuickAddGroups | data/DataModel |
| Role | data/DataModel |
| SelfServiceFeatureDisplayPolicy | data/DataModel |
| SelfServiceLinks | data/DataModel |
| SelfServiceTranslation | data/DataModel |
| Theme | data/DataModel |
