Permission definition

Hierarchical semantics

The following aspects display the fundamental problem of using an input component for the permission definition:

1. The groups usually form a hierarchy which has to be normalised appropriately. This means conversely: Users with special functions have to be normalised as a separate group.
2. The stores also form a hierarchy which is often used for inheriting permission definitions.
3. A modification of inherited permissions is desired.

The interconnection of these three aspects results in a significant complexity for permission definition, since:

1. there needs to be a definition of what occurs when a subgroup is allowed to do something that a superordinated group is not. Analogue: Prohibition
2. the semantics of the store has to be defined:
   a) none (e.g. Media-Store/Page-Store), i.e. only inheritance.
   b) hierarchy (e.g. navigation via the Site-Store), i.e. inheritance and limitation
3. a distinction between “allowed”, “prohibited” and “inherited” is required.

Hierarchical semantics (groups)

A group hierarchy is an organisation in which groups can consist of individual groups.

In FirstSpirit, permissions can be defined on each group hierarchy layer which is located (in the permission definition component) below the root node. This functionality has numerous advantages, especially when configuring user permissions, since it is possible to define permissions on a superordinated group which are subsequently valid for all subgroups. This means the number of required configurations can be kept to a minimum even for numerous groups.

In the FirstSpirit permission component, it is possible to define one of the following values on each group hierarchy layer below the root node:

• Allowed
• Forbidden
• Inherited (i.e. corresponds to the setting of the superordinated group)

Permissions can be defined on each layer – the FirstSpirit permission component does not make any assumptions regarding the "correctness” of the configuration. Plausibility checks or validations can be realised project-specifically.

The introduction of group hierarchies also leads to a number of problems:

1. What happens with “contradictions”, e.g. when a subgroup is allowed to do something that the superordinated group is not?
2. Is a superordinated group an independent entity?
3. What happens if the group hierarchy changes?

Since it is impossible to answer these questions universally for each application case, the user permission concept offers a means to map all possible answers. This means:

1. The list of the allowed and forbidden groups is managed separately and can be evaluated individually. Individual priority strategies can, therefore, be realised.
2. A superordinated group is an independent entity if it has been allocated an ID. If an ID has not been defined, the ID of the group is “calculated” as the union of all the IDs of the subgroups.
3. Changes to the group structure are covered via ID maintenance and notification mechanisms.

Hierarchical semantics (stores)

The permission definition is closely connected to the semantics of the stores. There are two possibilities:

1. no hierarchical semantics, except for inheritance (e.g. Media-Store/Page-Store)
2. Inheritance and constraint hierarchy (e.g. navigation via the Site-Store)

In the first case, the store tree does not define hierarchical semantics except for the inheritance (e.g. Media-Store/Page-Store). In this case, various anomalies might occur, e.g.:

• A user has the required permissions for a document but cannot access the document, since he/she does not have permission for the page to which the document is linked.
• A link can also point to a document for which the user does not have permission.

Both cases are actually incorrect configurations. However, they are difficult to detect and, therefore, difficult to prevent.

In the second case, the store defines a constraint hierarchy in addition to the inheritance hierarchy. This means the number of authorised persons along the tree can be limited, but not extended. This is recommended if the tree hierarchy has the form of a hierarchical menu, since access to a “subordinated” tree element can only take place via the “superordinated” node in this example. Therefore, a permission extension does not make sense, since the superordinated entry point is missing.

In summary, behaviour in the second case can reduce the chances of misconfigurations in certain cases. However, the configuration visualisation demands are higher.

The FirstSpirit implementation offers the required infrastructure to realise both variants.