GraphDB Users Ask: How Can I Break Up My Data to Control Access To It?

ONTOTEXT ANSWER:

As with most serious matters, the question of security is not simple to answer. We even have to briefly touch upon inference to fully understand the answer. Luckily, we have provided a robust mechanism already. All you have to do is configure it.

Data in GraphDB is stored in repositories. You can think about them as you would think about separate databases. The repositories are completely separate, with their own inference rules, SHACL shapes and – of course – security roles. The security roles here are three:

• user – with read or write permissions;
• repository manager – can access all repositories, delete and create them, and has read and write access to all of them;
• administrator – can also manage the cluster and security.

You can use SPARQL federation to access data across repositories. But to do that, you have to have access to the other repositories as well. This security model can be supported by a wide range of infrastructure. We offer a default internal user database, but can also cover users coming from LDAP, OAuth, Kerberos, OpenID.

As GraphDB handles a knowledge graph, many users would like to have security access over graphs or even particular triples. Unfortunately, this is not covered by the database alone. Mainly because of our inference model, but also because of performance considerations. Remember that GraphDB uses materialization (you can check out our previous blog post for a quick explanation). So, when you are uploading data, can you use data in other graphs for inference? In our model, the answer is “yes”. If security covered the named graph or triple level, for each insert, the database would have to look up the security model of the entire database. Furthermore, when inferring new statements, where should they be stored? Do you have read access over that particular graph? How about write access? You see why this model would quickly become unsustainable.

Fortunately, we already have an answer to this problem. Ontotext Platform comes to the rescue.

The Platform offers a very powerful Role Based Access Control (RBAC) mechanism, which allows you fine grained control over your data at the object level. This is done by applying filters on the incoming GraphQL query, before turning it to SPARQL. So, you may have read access to all objects of the type Customer. Or, perhaps, only to objects of the type EuropeanCustomer. The granularity of operations is also greater. There’s read and update/create permissions, but also delete permissions. With this security model, you don’t need to use named graphs or awkward triple-based rules. The Platform allows you to handle security at the most logical level – directly to objects. That’s how data is usually modeled, allowing you to make as little changes to the knowledge graph as possible.

Did this help you solve your issue? Your opinion is important not only to us but also to your peers.