An Access Control Policy is a collection of rules describing whether a given access request is permitted or denied.
The main challenge of designing an access control policy is to understand and analyse the evaluation of a given policy according to an access request.
An Access Request can be understood as set of attribute values, represented here by an element NAME_v, which is true if the attribute NAME has the value v, false if the attribute NAME does not have the value v, or unknown if we do not know whether the attribute NAME has the value v or not.
In the following, we will give you a policy and an access request and we will ask you to change the values of some attributes in order to obtain a specified decision (either Permit or Deny).
In general, a policy is a collection of access rules, which should collectively cover all possible cases in order to know what should be done in every situation.
An Access Rule is defined by associating a decision, such as Permit or Deny, with a condition over attribute values.
Rules are combined using composition operators, which specify how to combine the different decisions returned by the rules.
There are two main composition operators: permit-overrides (POV) and deny-overrides (DOV). Intuitively speaking, POV returns Permit if any rule returns Permit; it will return Deny if any rule returns Deny; and NotApplicable if no rule returns Permit or Deny. Similarly, DOV returns Deny if any rule returns Deny; it will return Permit if any rule returns Permit, and NotApplicable if no rule returns Permit or Deny.
Operators section describes in detail the composition operators.
For instance, in order to indicate that any student who has not paid gym membership is denied access to the gym, one could define the following access policy:
PA: Deny if FEE_due
If FEE_due is true, then this particular rule evaluates to Deny . However, if FEE_due is false, then this rule evaluates to NotApplicable. This distinction is very important, as one could have expected this rule to evaluate to Permit if FEE_due were false, however, rules describe as little as possible, and do not directly specify what happens if the condition they specify is not true.
In addition, if FEE_due is unknown, then this rule evaluates to Indeterminate(D), indicating that some information is missing but that this rule could have evaluated to Deny.
PB: Permit if NEWCASTLE_student
In a similar way as above, this rule evaluates to Permit if NEWCASTLE_student is true, NotApplicable if NEWCASTLE_student is false, and Indeterminate(P) if NEWCASTLE_student is unknown.
PC: POV(PA, PB)
We then create a policy by composing the rules PA and PB together. In this case, if NEWCASTLE_student is true, then PB evaluates to Permit, and therefore PC also evaluates to Permit, regardless of the value of FEE_due. On the other hand, if NEWCASTLE_student is false, then PB evaluates to NotApplicable. In such a case, if FEE_due is true, then PC will evaluate to Deny, whereas if FEE_due is false, then PC will evaluate to NotApplicable. The main intuition here is that the policy does not care if the fee is paid, as long as the person requesting the access is a student.
The choice of the composition operator is crucial to the evaluation of the whole policy. Other operators are described in the Operators section
The following sub-sections show the most common composition operators used in access control policies. Please notice that not all of the operations are commutative (Not all tables are symmetrical).
Please bear in mind that VisABAC uses line conventions to represent different composition operators.
Deny-Overrides
DOV | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
---|---|---|---|---|---|---|
Permit | Permit | Deny | Permit | Permit | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Deny | Deny | Deny | Deny | Deny | Deny | Deny |
Not Applicable | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Permit) | Permit | Deny | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Deny) | Indeterminate (Permit-Deny) | Deny | Indeterminate (Deny) | Indeterminate (Permit-Deny) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Deny | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Visual Representation
Given the following policy P=DOV(R1,R2) where {R1,R2:not applicable}; P is represented by the following line:
Permit-Overrides
POV | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
---|---|---|---|---|---|---|
Permit | Permit | Permit | Permit | Permit | Permit | Permit |
Deny | Permit | Deny | Deny | Indeterminate (Permit-Deny) | Deny | Indeterminate (Permit-Deny) |
Not Applicable | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Permit) | Permit | Indeterminate (Permit-Deny) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Deny) | Permit | Deny | Indeterminate (Deny) | Indeterminate (Permit-Deny) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Permit-Deny) | Permit | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Visual Representation
Given the following policy P=POV(R1,R2) where {R1,R2:not applicable}; P is represented by the following line:
Deny-Unless-Permit
DUP | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
---|---|---|---|---|---|---|
Permit | Permit | Permit | Permit | Permit | Permit | Permit |
Deny | Permit | Deny | Deny | Deny | Deny | Deny |
Not Applicable | Permit | Deny | Deny | Deny | Deny | Deny |
Indeterminate (Permit) | Permit | Deny | Deny | Deny | Deny | Deny |
Indeterminate (Deny) | Permit | Deny | Deny | Deny | Deny | Deny |
Indeterminate (Permit-Deny) | Permit | Deny | Deny | Deny | Deny | Deny |
Visual Representation
Given the following policy P=DUP(R1,R2) where {R1,R2:not applicable}; P is represented by the following line:
Permit-Unless-Deny
PUD | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
---|---|---|---|---|---|---|
Permit | Permit | Deny | Permit | Permit | Permit | Permit |
Deny | Deny | Deny | Deny | Deny | Deny | Deny |
Not Applicable | Permit | Deny | Permit | Permit | Permit | Permit |
Indeterminate (Permit) | Permit | Deny | Permit | Permit | Permit | Permit |
Indeterminate (Deny) | Permit | Deny | Permit | Permit | Permit | Permit |
Indeterminate (Permit-Deny) | Permit | Deny | Permit | Permit | Permit | Permit |
Visual Representation
Given the following policy P=PUD(R1,R2) where {R1,R2:not applicable}; P is represented by the following line:
First-Applicable
FA | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
---|---|---|---|---|---|---|
Permit | Permit | Permit | Permit | Permit | Permit | Permit |
Deny | Deny | Deny | Deny | Deny | Deny | Deny |
Not Applicable | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) |
Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Deny) |
Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Visual Representation
Given the following policy P=FA(R1,R2) where {R1,R2:not applicable}; P is represented by the following line:
Only-One-Applicable
OOA | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
---|---|---|---|---|---|---|
Permit | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Permit | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Deny | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Deny | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Not Applicable | Permit | Deny | Not Applicable | Indeterminate (Permit) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Deny) | Indeterminate (Permit-Deny) | Indeterminate (Deny) | Indeterminate (Permit-Deny) |
Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) | Indeterminate (Permit-Deny) |
Visual Representation
Given the following policy P=OOA(R1,R2) where {R1,R2:not applicable}; P is represented by the following line:
Authoring and editing access control policy can be a complex and cognitive demanding task, especially when dealing with a large number of rules and attributes. Visualisation techniques are known to be helpful to users analysing intricate data, and can, in some contexts, help decreasing the cognitive load.
VisABAC enables the visualisation of attribute based access control policies using the Zoomable Circle Packing technique.
A circle is either an ABAC rule or a composition of ABAC rules grouped by a composition operator.
As a consequence, a policy comprised of sub-policies is represented by circles containing sub-circles in a similar hierarchy as the given policy.
For example, the visualisation in VisABAC of the following policy:
Under the following attribute values:
It is the following figure:
Figure shows that Level 0 (P) represents the whole policy by the most outer circle line; Level 1 (R1 and R2) represent the first level of the tree policy with smaller circles inside. Clicking on the inner circles activates a zoom that would display their respective targets, since they are atomic policies:
The corresponding console evaluation for the given policy gives additional details to the user:
Circles are coloured according to the result of the policy they represent.
Green (or blue [2]) is for Permit, red (or mustard yellow[2]) for Deny , white for NotApplicable, patterned-green for Indeterminate(P), patterned-red for Indeterminate(D), and patterned-grey for Indeterminate(PD).
[2] There is a colour deficiency mode, selectable through preferences, which caters for different types of colour deficiencies. In this mode, a shade of blue is used instead of green; A shade of yellow is used instead of red.