Attribute-Based Access Control with a graph database

Traditional access control relies on the identity of a user, their role or their group memberships. This can become awkward to manage, particularly when other factors such as time of day, or network location come into play. These additional factors, or attributes, require a different approach, the US National Institute of Standards and Technology (NIST) have published a draft special paper (NIST 800-162) on Attribute-Based Access Control (ABAC).

This post, and the accompanying Graph Gist, explore the suitability of using a graph database to support policy decisions.

Before we dive into the detail, it’s probably worth mentioning that I saw the recent GraphGist on Entitlements and Access Control Management and that reminded me to publish my Attribute-Based Access Control GraphGist that I’d written some time ago, originally in a local instance having followed Stefan Armbruster’s post about using Docker for that very purpose.

Using a Property Graph, we can model attributes using relationships and/or properties. Fine-grained relationships without qualifier properties make patterns easier to spot in visualisations and are more performant. For the example provided in the gist, the attributes are defined using solely fine-grained relationships.

The model

For this fictitious sample, we’ll use Subjects to represent the identifiable users and Objects to represent security classified items that are under access control. The first basic check is that the Subject has the correct level of security clearance to access the object.

Primary entities

Classification levels

Modelling and querying the classification levels isn’t quite as straightforward because a user can access information classified at lower levels than their clearance, but obviously never above. This can be handled by relationships showing the hierarchy of classification levels e.g. (secret)-[:IS_LOWER_THAN]->(topsecret). We can the match down the classification levels (so the object marking is less than or equal to the clearance of the subject):

MATCH (s:Subject)-[:CLEARED_TO]->(cls:ClassificationLevel)<-[:IS_LOWER_THAN*0..4]-(clo:ClassificationLevel)<-[:MARKED]-(o:Object)
WHERE = "Wanted list"
RETURN as Subject

Additional attributes

In the gist these include Citizenship and Organisation, with the sample graph looking like:

Who can access a specific object?

We can use multiple matches using the WITH clause to perform the classification level check (from earlier) in conjunction with citizenship and organisational membership checks. These are built up in the graph gist, the final query is:

MATCH (o:Object { name: "Wanted list" })-[:MARKED]->(clo:ClassificationLevel)-[:IS_LOWER_THAN*0..4]->(cls:ClassificationLevel)<-[:CLEARED_TO]-(s:Subject)
WITH o, s, cls
MATCH (s:Subject)-[:CITIZEN_OF]->(c:Country)<-[:VISIBLE_TO]-(o:Object)
WITH c, o, s, cls
MATCH (s:Subject)-[:MEMBER_OF]->(org:Organisation)<-[:VISIBLE_TO]-(o:Object)
RETURN as Subject, as Clearance, as Organisation, as Country


In conclusion, the flexibility of the graph model is perfect for representing the data for policy decisions – i.e. the Attribute Repository but it could also encompass Environment Conditions (see Figure 5 in NIST 800-162).
Whilst it would be implementation specific, the Policy Decision Point might leverage a business rules engine to apply further query criteria/filtering of results according to the locally administered policies.


One response to “Attribute-Based Access Control with a graph database

  1. Pingback: Attribute-Based Access Control with a graph database [Topic Maps at NIST?] « Another Word For It

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s