Attribute Based Access Control
Restorecommerce features an attribute based access control model (ABAC) which is heavily inspired by XACML. XACML is pretty complex but very powerful, which is why Restorecommerce narrows it down to a profile consisting of the essential bits and pieces for JSON driven APIs. We use the concepts of XACML as follows with XACML terms in italics:
-
The Subject is determined by the defined authentication service.
-
A role represents a single Policy.
-
Policies may have multiple Rules.
-
The Target of a rule consists of the resource it applies to, the performed actions and an associated scope.
-
The Effect of a rule is always Permit (white listing).
-
There is no pendant to the Condition, Advice, Obligation and Environment rule components.
-
JSON based syntax instead of XML.
XACML building blocks relate to Restorecommerce as follows:
-
The PIP (Policy Information Point) is the endpoint of the
role
resource. -
An API is implicitly a combined PDP/ PEP (Policy Decision/ Enforcement Point).
-
The PAP (Policy Administration Point) is the API for accessing security related resources.
There is a single Rule type with the following Target attributes:
-
Resource IRI (
res
). -
Action mask (
mask
) where the most permissive mask is:crud
. -
Scope (
scope
).
The rule combining algorithm is simply to permit the Authorization Request if at least one rule applies (logical or). If there are no matching target attributes for a request, the effect is a deny.
Authorization Requests corresponding to this rule type take the following form:
-
Subject attributes:
-
subject with an IRI as value.
-
-
Resource attributes:
-
resource with an IRI as value,
-
scope value as defined above.
-
-
Action attributes:
-
action with possible values:
c
,r
,u
,d
as described above.
-
The scopes are evaluated with their set relationship taken into account;
For example a request for a resource with scope user
which is in fact owned by the subject and the subject is granted access to the scope app
, succeeds as it includes user
.
PAP-wise, the following is important:
-
Roles are the vehicle to delegate access rights but they are never used to make authorization decisions by solely the fact that a subject has assigned a BR. Only the rules in the policy of a role are considered.