Data Access Security¶
VOSS Automate secures access to data with the concepts of data partitioning via hierarchies, and user roles.
Data Partitioning and Hierarchies¶
Using hierarchies to partition data means that an administrator user is only allowed to view and perform operations on entity instances that are provisioned at the parent hierarchy of the hierarchy where they have access.
Access to resources is thus based on the user’s parent hierarchy. This restriction is enforced in API middleware for every requested operation. Partitioning is enforced across the various system interfaces, for example loaders, API, and the Admin Portal. This means that an administrator user for customer “VS-Corp” cannot view or act on data at customer “GenCorp”. The “VS-Corp” administrator can only view and act on entities assigned to “VS-Corp” or its child hierarchy levels (sites).
Note
When an administrator navigates to a particular hierarchy they may have read-only access to model instances created at a higher level of the hierarchy. For example, a provider administrator’s view of the list of menu layouts may show instances created above the provider’s hierarchy. In this case, the administrator requires read-only access in order to have the ability to clone a field display policy at a lower level of the hierarchy. This administrator will not be able to edit the model instance created at the higher level of the hierarchy. However, a provider administrator viewing the list of model instances below the provider level is able to edit model instances created at the provider hierarchy.
When the model is designed, the following setting is enabled: Visible at Lower Hierarchy
This setting is available for Data, Domain, and Relation definitions. For Relations, the setting overrides the setting in any related models. See the table below.
User Roles, Access Profiles, and Data Security¶
Access profiles define the read and write permissions assigned to user roles. The access profile defines how the user can interact with specific system entities. Permissions include details of each entity type in the system, as well as the relevant privileges related to that entity type. See Role-based Access.
Hierarchy - defines the specific instances of the various entities that the user can interact with
User’s role and access profile - determines the permitted operations that can be performed on these instances.
The table describes models with 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 |