Jena Security with Reification

Question

Given this example RDF how could I use jena security to only retrieve values where user role matches ex:role?

_:statement rdf:type rdf:Statement .
_:statement rdf:subject dbr:Ireland .
_:statement rdf:predicate dbo:capital .
_:statement rdf:object dbo:Dublin .
_:statement ex:role "ROLEA", "ROLEB", "ROLEC" .

_:statement rdf:type rdf:Statement .
_:statement rdf:subject dbr:Canada.
_:statement rdf:predicate dbo:capital .
_:statement rdf:object dbo:Ottawa .
_:statement ex:role "ROLEA" .

I am not sure how to accomplish this given jena Security (ie SecurityEvaluator). Thanks.

Answer 1

There is minimal information provided in your question. I will attempt to answer and will attempt to identify the assumptions I am making.

I am using the term "base graph" to mean the graph that you are querying. This may be a combination of multiple physical graphs. It is the graph that contains the data that will be queried and returned to the user.

I am using the term "security graph" to mean a graph that stores data about security access.

First I assume that you have a mechanism to associate the logged in user with the roles the user has access to. This may be a list of roles for a user or a method that returns true if the user has a specific role. Implementation details aside, there is a method to determine that a user has a role.

Second I assume from your question that you want to check each triple in the base graph and that the reification of each triple is stored in the "security graph". This means that your security graph will be much larger than your data graph. If you are only interested restricting access to triples that have a predicate of dbo:capital it might be better to create a new type that has the dbr:country what groups have access to the country. But for now I will proceed on the assumption that you will create the reified statements with the role property and that you will do this for each triple that you are interested in restricting.

The "security graph" must be accessible from within the SecurityEvaluator (this is part of setting up the evaluator).

Third assumption the data graph is identified by the graph name "urn:graph-name:data-graph".

When the triple <dbr:Ireland, dbo:capital, dbo:Dublin> is read from "urn:graph-name:data-graph"

The method SecurityEvaluator.evaluate( Acton.Read, "urn:graph-name:data-graph" ) will be called first. The Evaluator should return "true" to indicate that the user has read access to the graph.

Second the method SecurityEvaluator.evaluate( Action.Read, "urn:graph-name:data-graph", SecTriple.ANY ) will be called. The SecurityEvaluator should return "false" to indicate that that there are restrictions on some triples in the data graph. If you have a role that can read all the data elements you could return "true" here for users that have that role.

Finally the method SecurityEvaluator.evaluate( Action.Read, "urn:graph-name:data-graph", <dbr:Ireland, dbo:capital, dbo:Dublin> ) will be called. The evaluator should then look up the rdf:Statement that covers the <dbr:Ireland, dbo:capital, dbo:Dublin> triple, retrieve the roles that have access, compare those with the roles that the user has and if there is an intersection return "true" otherwise return "false".

A couple of things to consider:

Often the security/permissions system is concerned with access to specific properties of objects, working out how to store those properties with roles will often reduce the size of the "security graph" and will make the system more efficient.

Using reification to identify triples that need to be filtered means that if someone adds a new triple say <dbr:Ireland, dbo:capital, "Dublin"> The triple will not be blocked.

If the triple <dbr:Ireland, dbo:capital, dbo:Dublin> exists in 2 graph that are combined to make one dataset and you only filter one graph the data will like. This is intentional.

In this discussion I used the term "security graph". I did this because your example used reified triples to describe the data. There is no requirement to use a graph to store the security restrictions. It is often easier to do so because the graph manipulation code is already at hand, but it is not required. Any solution that will allow you to lookup the restricted components of the triples will work.

I hope this helps.