Understanding Permission Rules and Rulesets

As described in Section Defining Permission Rules and Rulesets, permission rules are gathered in rulesets.

A ruleset is attached either to:

  • An application element,

  • A permission group, or to

  • The application itself.

The matching part of a permission rule is made of a user pattern, an access right, and an application element type. When performing an operation on a given application element, the following rulesets are searched in this order until at least one positive match is found:

  1. the ruleset attached to the application element;

  2. the ruleset attached to the element that contains the application element, if any;

  3. the rulesets attached to the permission groups that contain the application element;

  4. the rulesets attached to the permission groups that contain the element that contains the application element, if any;

  5. the ruleset attached to the application.

    Note:

    Note that, for creation requirement, the application element considered is the candidate container, if any. If it is null, only the ruleset attached to the application is searched.

In the example of the requirement "User Alice needs MODIFY access right on scenario S1" where:

  • S1 belongs to permission groups G1 and G2,

  • S1 is contained in workspace W1, which belongs to permission groups G3 and G4,

The following rulesets would be searched:

  1. First, the one attached to S1;

  2. Then the one attached to W1;

  3. Then the ones attached to G1 and G2;

  4. Then the ones attached to G3 and G4;

  5. And finally, the one attached to the application.

When the search is conducted on the rulesets attached to the permission groups that contain a given element (steps 3 and 4 above), all the rulesets that contain the elements are searched before deciding to stop or proceed.

As a result, the collected rules may come from several rulesets at these steps. If one of the lookup steps above yields a collection of two permission rules or more, only the most specific ones are retained. The specificity of a permission rule is determined by that of its user pattern. That is, in decreasing order of specificity: USER(u), OWNER, ROLE(r), EVERYBODY. This specificity filter is useful when a ruleset defines a permission rule for the general case using EVERYBODY, and another rule for a more specific case, for example, using ROLE(r).

If both rules are applicable, this selection step retains only the one for the role. Note that even after this selection, several rules with the same specificity may be applicable. This may, for example, occur when the user in the access requirement holds several roles. This is not a problem, and is addressed in the next step.

If one rule or more were found and selected, the operation is allowed if all the decision parts of these rules are true, and forbidden if the decision part of at least one rule is false.

If no applicable rule was found, the operation is allowed.