RelBAC: Relation Based Access Control
Opened this issue · 9 comments
There are a number of very interesting papers from 2008 on on a form of Access Control called RelBac. This was developed and illustrated with reference to the Semantic Desktop Work - a large EU project that was going around that time. It proposes to formalise access control in terms of Description Logics ie, OWL and is not far either WAC or ACP.
Papers:
- 2008 - RelBac: Relation Based Access Control
- 2009 - Design and Run Time Reasoning with RelBAC
- 2015 - A Practical Framework for RelBAC Implementation
Looking for feedback on implementations, relevant papers, potential limitations, summaries of good ideas we can use here.
What's the functional difference between RelBAC and ABAC (Attribute Based Access Control, sometimes referred to as Rule Based Access Control)? It seems (at quick glance; I've not read much of the papers you linked yet) like these may be roughly if not completely synonymous. (Both of these are in contrast to RBAC, Role Based Access Control, which is common in DBMS).
The first paper on RelBAC argues for it being an extension of RBAC.
In a way RDF/OWL should be a perfect tool to do ABAC: we just need to think of relations as attributes, et voilà.
But a formal mapping would be ideal. Yet according to this 2017 Review of the literature (170 papers) there was at the time no agreed formal specification yet of ABAC. They point this out as a major todo. So it would be difficult to get a definitive answer to that question. The review does list quite a few papers that use Semantic Web Technologies for ABAC, from 2008 onwards.
I'll keep searching.
I'll give a quick summary of what is interesting about RelBAC.
First of all it is extremely simple. There are just three types of things which I'll translate to our language
- Agents, which they call Subjects, Users or Groups, as in the literature.
- Resources, which they call Objects
- Permissions - which relate Agents and Resources.
They then work using Description Logic formalism which is concise, but I'll translate to Turtle and OWL which avoids us having to learn a new language, and adapt it a little to our use case.
We can use foaf for the Agent class and gen for the Information Resource class. This leave the permissions that we can specify using a new RelBAC ontology. I will give in the prefix can as I think that works out nicely.
foaf:Agent a rdf:Class .
gen:InformationResource a rdf:Class .
can:permission a rdf:Property;
rdfs:domain foaf:Agent;
rdf:range gen:InformationResource .Permissions can inherit from one another.
can:read a rdf:Property;
rdfs:subPropertyOf can:permission.
can:append a rdf:Property;
rdfs:subPropertyOf can:permission ;
rdf:comment "RelBac does not specify this one, but it does have others such as a CanSign permission".
can:write a rdf:Property;
rdfs:subPropertyOf can:read, can:append .What is interesting then is how rules and policies are defined.
- Rules are just the instantiation of
permissionsto a specific set of users or a specific set of resources. - Policies are sets of access control rules.
So assuming on my Pod I have a group :myFamily and a set of Resources called :FamilyPhotos .
:myFamily rdfs:subClassOf foaf:Agent .
:FamilyPhotos rdfs:subClassOf gen:InformationResource;
rdfs:comment "this could be defined as all photos inside a container, recursively".then I think one can write
:myFamily rdfs:subClassOf [
a owl:Restriction;
owl:onProperty can:read;
owl:allValuesFrom :FamilyPhotos ] .Except that that is not quite right, because the restriction selects those agents that only have read access to elements of that collection, and of course my family should have access to a lot more, not just on my server but on their own pod too. Existential quantification (replacing owl:allValuesFrom with owl:someValuesFrom) would be too weak: it would say that my family is a subset of those people who can look at some photos.
So perhaps it would be better to think of :myFamily as a permission that applies to only those resources, and then one would need to assign that permission to a group of people somehow.... Hmm.
I may want to check the other papers to see how this was implemented....
What is noteworthy is that RelBAC does have a very simple way to express access control facts.
Each fact is just a simple triple such as:
:Tim can:write <card> .In WAC this would be:
[] wac:accessTo <card>;
wac:mode wac:Write ;
wac:agent :Tim .Looked at this way, it looks like WAC is essentially a reification of the RelBac model
But interestingly there is also another way to write WAC statements:
<#familyCanView> wac:accessToClass :FamilyPhotos;
wac:mode wac:Read;
wac:agentClass :myFamily .and this looks very much like a relation definition, something like this:
<#familyCanView> rdfs:subPropertyOf can:read;
rdfs:domain :myFamily ;
rdfs:range :FamilyPhotos .This would then allow a Guard to work out that the following statement should grant read access:
:mom <#familyCanView> <BlowingCandles> .And this seems like the right way to achieve what I was trying to achieve a few comments further up, by relating groups and resources using OWL. So in this view WAC is a way to create new types of relations which RelBac calls Permissions.
For an argument by example that RelBAC can do ABAC see my response on issue 147.
On closer reading there is an interesting limitation of RelBAC with regard to OWL relating to rules.
The DL formalism named ALCQIBO is concisely formulated in the 2009 paper Using Description Logics in Relation Based Access Control. This can be mapped to OWL2, except for Role Negation, which we would also call relation negation.
This is needed to write statements such that All users have access to all objects, which they call Total Access Control rule.
But in OWL2 we don't have Role Negation so this cannot be written out there. Luckily as pointed out in the 2015 paper A Practical Framework for RelBAC Implementation the mapping to SWRL rules is very simple:
So one question for us is whether we should interpret WAC statements as descriptions of relations as above or rather as such SWRL rules.
Note that in Rui Zhang's 2009 PhD dissertation RelBAC - Relation Based Access Control (published later as a book) the mapping to SWRL is already pointed out clearly in §9.3 "All Rule Implementation" and in 3.5 the All Rule is explained clearly. It is key in allowing the mapping to RBAC.
I read the paywalled 2020 paper ChRelBAC data access control model for large-scale interactive informational-analytical systems that describes an applyication of RelBAC to a large Russian Scientometric system, which as I understand are large social networks for scientists. They felt the need for RelBAC for the flexibility it gave them, and they felt the need to extend RelBAC in order to allow for chains of relations. They seem to have implement their network in Django.
The need to extend RelBAC stems from too literal an interpretation of it. I can see that one would come to that conclusion if one took RelBAC descriptions as being limited to groups of Agents and relations between Agents and groups of Information Resources. But of course if one looks at using RelBAC within the Semantic Web framework, then one can see that any type of semantic web relation can be used to narrow in on agents, including relations to places, times other people, organizations, weather conditions, etc... Furthermore OWL gives one the notion of property chains so the tools are there ready to be used.
The system they built is also centralised. Users are identified with accounts on the system, and the ontology can be extended but from within the system. This explains their not looking in the direction of OWL or LinkedData, which is the fundamental differentiating point of Solid.
Here's a paywall-free pathway to read ChRelBAC data access control model for large-scale interactive informational-analytical systems in your browser.
As with many papers, you can also request a PDF direct from the authors. This site linked above offers a few buttons to help with that process.