Permissions Model - Inheritance and Conflicts
The following is an overview of the SuperSTAR permissions model, explaining how inheritance of permissions works, and what happens if there are conflicts between permissions:
| Summary | Description | ||||||
|---|---|---|---|---|---|---|---|
| Granting dataset access allows full access by default | By default, when you give a user access to a dataset, that user can access all dataset components. You need to specifically set permissions at the field level if you want to change that. | ||||||
| You can set permissions for users, groups, and all users | You can set permissions for:
| ||||||
| Permissions are inherited in hierarchies | Permissions set at a given level in a hierarchy will be inherited by that level's children. For example, if you set permissions for a hierarchical field like the following, then any permissions set at level A will be inherited by B and C:
| ||||||
| Deny permissions take precedence in hierarchies | If you deny access to a given level in a hierarchy, the user will not be able to access any level below that in the hierarchy. This applies regardless of any security settings that have been specifically set a lower level in the hierarchy. For example, in the following hierarchy:
If you deny the user access to level B, that user will not be able to access C, regardless of any other security settings that have been applied to C. | ||||||
| With conflicting group permissions, deny permissions take precedence | If a user belongs to multiple groups that have conflicting permissions, then if any one of the groups that the user belongs to has specific deny permissions set for a field or dataset, the user will not be able to access that item. However, if the user belongs to one group that has allow permissions for a field or dataset and belongs to another group where no specific permissions are set for that field or dataset, then the user will be able to access that item. For example:
| ||||||
| User permissions override group permissions |
| ||||||
| Permission overrides are not inherited | If you want to override a permission that is defined at the "allusers" or group level you must explicitly override it at every level in the hierarchy where you want the override to apply. For example, in the following hierarchy:
If the group permission denies access to B, and you override that permission at the user level for B, then that user will not be able to access C. To override the group permission and allow the user access to both B and C you would have to explicitly override that permission for that user at both level B and level C. |