Before creating or editing rules, we will take a closer look at the principles behind the access policies in AMS. This is quite important given the possible confusion coming up when there is more than one rule applying to a certain domain. There are two situations in particular that are potentially confusing:
Suppose that node A has a rule allowing user X to read annotation files. That means that user X is allowed to read all annotation files in the domain of node A (i.e. annotation3 in Figure 3.1). Now say that one of the ancestors of node A, specifically node B, has a rule denying user X to read annotation files. That means that user X is not allowed to read any annotation file in the domain of node B. If we consider that the domain of node A is in fact part of the domain of node B, we see that the rules of both nodes are in conflict.
Suppose that a node has two rules (see Figure 3.2). One rule allows user X to read annotation files. The other rule denies group G to read annotation files. Consider user X to be a member of group G. That means that the two rules concern user X, one allowing and the other denying user X to read annotation files. Again, the two rules are in conflict.
Only rules that apply to the same resource type (like the annotations in the examples above) can conflict. If two rules do not apply to the same resource type they cannot conflict.
The fact that rules may conflict raises the question of how AMS determines whether a user is allowed to read or to open a resource. To be able to answer this question we state the following basic principles:
A rule either allows or denies the access to a resource for a specific user or for all the members of a group.
To calculate the access rights of a resource all rules in the path are taken into consideration.
A rule can have the following priority levels:
Highest
High
Normal
![[Note]](images/note.png)
Note Only users with the Archive Manager role can use the highest level of priority when adding and editing rules.
Now that we have seen what basic principles are involved in the calculation of the access rights, we state the principles of the calculation itself. These principles are applied by AMS in the same order as we show them here:
The priority principle: The highest priority of the considered rules is determined, and all rules with a priority lower than that are outvoted.
The closeness principle: From the nodes in the path that have at least one rule, only the rule from the node which is closest to the resource is kept. All other rules are outvoted. Consider for example the path A-B-C-D-resource (top down). If both node A and node C have a rule, only the rule on C is kept. The rule on node A is outvoted.
The constraint principle: If a) there is more than one rule applying to the same resource type, and b) the rules have equal priority, equal closeness and c) they are conflicting (at least one is denying and one is allowing a user to read a resource), access to the resource is denied. So denial outvotes permission.
To sum up, AMS first selects rules with the highest priority. Then, it selects rules on nodes closest to the resource from the remaining rules. Finally, it looks whether one of the remaining rules denies access to the resource. By applying the calculation principles in this way, AMS avoids conflicting situations as described at the beginning of this section.
The following three situations exemplify how the access rights are calculated from all considered rules:
Example 1
Consider the following path with the nodes listed in top down order and their corresponding rules:
| Node A: Top Node | Rule 1: Read Annotation Files Allow (normal priority) for user X |
| Node B | Rule 2: Read Annotation Files Deny (normal priority) for user X |
Node C: Resource - annotation file test.txt | - |
Both rules concern the reading of annotation files by user X and both
rules have the same priority. This results in a conflict. In this example rule 1 allows
user X to read the annotation file test.txt on node C, whereas rule 2
denies the file to be read by user X. Since both rules have the same priority, AMS cannot
make a choice based on the priority principle. Therefore, AMS applies the closeness
principle, according to which only rules from nodes that are closest to the resource are
weighed heavier. Applying this principle results in the outvoting of rule 1 leaving only
rule 2. Since rule 2 denies reading annotation files, AMS also denies user X to read the
annotation file test.txt.
Putting rule 2 on node A and rule 1 on node B results in the discarding of rule 2
based on the closeness principle. The remaining rule 1 results in AMS allowing user X to
read the annotation file test.txt.
Example 2
Now focus on this second path:
| Node A: Top Node | Rule 1: Read Annotation Files Allow, highest priority for user X |
| Node B | Rule 2: Read Annotation Files Deny, high priority for user X |
| Node C | Rule 3: Read Annotation Files Deny (normal priority) for user X |
Node D: Resource - annotation file test.txt | - |
One of the three rules in this example allows user X to read the
annotation file test.txt, while the other two deny reading the file.
Moreover, all three rules have a different priority level. Applying the priority principle
results in the outvoting of rule 2 and 3 because only rule 1 has the highest priority
found in the three rules. The final result is that AMS allows user X to read the
annotation file of node D.
Example 3
A slightly more complicated example is the following path:
| Node A: Top Node | Rule 1: Read Annotation Files Deny, high priority for user X | ||
| Node B |
| ||
| Node C | Rule 4: Read Annotation Files Deny (normal priority) for user X | ||
Node D: Resource - annotation file test.txt | - |
Applying the priority principle discards rule 4 because the highest priority level is high and rule 4 has a lower priority level. This leaves rule 1, 2 and 3. Applying the closeness principle discards rule 1 leaving rule 2 and 3. Since we are interested in the access rights of user X and user X is a member of group G rule 2 and 3 are still in conflict. So, AMS applies the constraint principle. This means that if there is still a rule denying the right to read a resource, that rule is applied to calculate the final access right.
As far as access rights calculation is concerned, you may need to use the option Force export.
After submitting a workspace in Lamus, AMS is automatically triggered in order to recalculate the previously set access rights. However, it may happen that, for some reason, AMS does not manage to trigger such recalculation, leaving the user without access.
By selecting the option Force export, located under Add new rules (see image below), you manually initiate the recalculation of the access rights. This should help you solve some of the access-related problems.
