Access Rights

Some of the key information that we talk about while defining and discussing access rights are as below:

  • User and User Groups are also called Principals.
  • The term permission has the same meaning as user access rights or access rights or user rights.
  • Permission is an abstract concept, sometimes also referred to as user rights.
  • By defining access rights (permissions), we can specify a very detailed level of access to the types, items, and their attributes for a particular user or user groups.
  • Groups can contain other groups or other users.
  • Access rights can be inherited from the groups higher in the hierarchy by the more specific principals lower in the hierarchy.
  • Types of Permissions: Global Permissions, Type Permissions, Item Permissions, and Attribute Permissions.
  • Permission Stages: Read, Change, Create, and Delete.
  • If a user is granted type permission: Read to the type while attribute permission: Read is denied, then the user would able to see all the type attributes except the particular one that has been denied.
  • While on the same level in the inheritance hierarchy, deny settings rank higher in priority than grant settings.  So, for a user who belongs to two different groups, one of which is granted a read permission to a type, while the other group is denied the same permission for the same type, the user inherits both permissions, however, the effective permission for the user is deny.
  • Global Permissions are assigned to the particular user or user group.
  • More specific permission assignment like type-, item-, or attribute permission overrides the global permissions regarding the particular type, item, or attribute.
  • Type related permissions define the user access rights to the type. The user with assigned permissions to the type also has default access to all type attributes.
  • Using attribute permissions allows us to explicitly assign permission to selected attributes of a certain type. Attribute-related permissions don’t override type-related permissions. For example, if the type permission for a type is set to deny, we cannot grant permission to any of the attributes of that type.
  • Using item permission assignments allows us to define very fine-grained access control in that we can grant or deny permissions to item instances. However, it is best to assign permission on a type level using principal groups.
  • Users can belong to the user groups. If a user group is assigned the permissions, then all the users belonging to that group inherit the same permissions.
  • It is a common approach that the permissions are not assigned to the user account directly, but to the user group instead. All members of that user group, both users or other user groups, automatically inherit those access rights.
  • A user account that is a member of the admingroup user group or users with uid: admin always have full access rights.
  • If the user group has no permissions assigned, then the permissions assigned to the closest user group one level up in the user group hierarchy are valid.
  • If no permission has been assigned throughout the user group hierarchy, then access right defaults to deny.
  • If user account is a member of several user groups not forming a hierarchy, then all permissions assigned to these user groups apply by inheritance to the user account. Again, deny setting for access rights rank higher than grant setting for access rights. It means that if the same access right (for example: read, change) is defined in a conflicting manner by parent user groups being on the same hierarchy level, then the deny setting rank higher than grant setting.

    For more information access rights please click here.

Managing Access Rights

We can manage user access rights using impex as demonstrated below.

$START_USERRIGHTS
			     Type;UID;MemberOfGroups;Password;Target;read;change;create;delete;change_perm
UserGroup;impexgroup;employeegroup;
;;;;Product;+;+;+;+;-
Customer;impex-demo;impexgroup;1234;

$END_USERRIGHTS

The syntax given above is described as below:

  • The $START_USERRIGHTS statement in line 1 indicates that every line until the $END_USERRIGHTS statement isn’t an ImpEx specific one, instead all lines between the two statements are redirected to the user rights management (accessManager).
  • The second line is the header and defines the attributes that are to be set. This header is specific for the user rights management and doesn’t support any features of ImpEx-like modifiers.
  • The third line sets the usergroup with the name impexgroup that is a MemberOfGroups (subgroup) of employeegroup as an item where you modify given access rights. The item is the current one until the next item definition. If we forget to set a type (here UserGroup), the action will have no effect.
  • The fourth line sets the permissions for impexgroup: + allows, – denies the respective access right. A skipped value specifies no override, that is, use the inherited setting.
  • The fifth line creates a user of type Customer named impex-demo. This user is a member of impexgroup, and their account password is 1234.
  • The sixth and last line ends the user right definitions section.

Access rights to an attribute of a type is defined as below:

$START_USERRIGHTS
			    Type;UID;MemberOfGroups;Password;Target;read;change;create;delete;change_perm
UserGroup;impexgroup;employeegroup;
;;;;Product.code;-;-;;;;
;;;;Product.ean;-;-;;;;

$END_USERRIGHTS