Security model of RDF4J - Howto model an Editor role

[volkerjaenisch]

Dear RDF4J!

After tinkering the security to work I have some questions on role modelling.

Most of the users of RDF4J will not use the security model at all.

• They will do science or dataminig never exposing RDF4J even indirectly to the web.
• Or they do not care like 99% of the Web-Developers out there: One admin role that can do it all and go!

So if we are talking about security we are talking about a percent of the RDF4J users, only.

This percent may consider a more cautious approach having two roles:

• Admin : Can do all.
• Query: Can only read the repositories.

This can be easily achieved with the RDF4J/Tomcat security.

And there are even more cautious users. We are now talking about a percentage of a percent of users.

I utilize Plone for more than a decade. It has an excellent security model equal to that of J2EE.
A Plone-Application has usually three roles:

• Admin : Can do all.
• Viewer: Can only read the repositories.
• Editor: Can do what Viewer can. And additionally the Editor can add, edit and remove data from the repository. But Editor cannot create or drop repositories.

Currently I am struggling with this Editor role in RDF4J.

• I grant the editor role the DELETE method on a repository, so it can delete datasets from the repository. But then the editor also can delete the repository itself.

• If I grant the editor the PUT method, to add datasets to an existing repository, then the editor also create a new repository with new data (if the repository does not exists).

[Maybe these two findings are not a fact, but caused by my faulty configuration.]

As I mentioned these are corner cases of corner cases, but probably they are interesting for someone trying to write a really secure Web-Application utilizing RDF4J, like me.

Please don't get me wrong. This is no RDF4J bashing. I am really happy with RDF4J. Formerly we utilized Blazegraph with no security at all.

But I have to understand the security model of a database quite good before I release a Python database adapter utilizing RDF4J to the public.

Cheers,
Volker

[abrokenjester]

I grant the editor role the DELETE method on a repository, so it can delete datasets from the repository. But then the editor also can delete the repository itself.

They're different endpoints though, so you should be able to differentiate them:

DELETE /rdf4j-server/repositories/<ID> <- removal of the repository itself

DELETE /rdf4j-server/repositories/<ID>/statements <- removing statements from the repository

If I grant the editor the PUT method, to add datasets to an existing repository, then the editor also create a new repository with new data (if the repository does not exists).

Likewise:

PUT /rdf4j-server/repositories/<ID> <- config/creation of the repository itself

PUT /rdf4j-server/repositories/<ID>/statements <- adding statements to the repository

What may be somewhat confusing is that the endpoint for executing SPARQL queries is also /rdf4j-server/repositories/<ID> . However, SPARQL queries can only be supplied using POST or GET requests.

[abrokenjester]

Also I noticed that for the endpoints /repository/* only XML and JSON query results are possible.
Results in Turtle are only possible via the /repository/*/statements endpoint.

That's actually not correct. Though of course you can only get back Turtle results via the /repository/* endpoint if you execute a CONSTRUCT or DESCRIBE query (so that the result is RDF triples, which can be serialized in Turtle).

[abrokenjester]

As for wildcards: you're right that you're a bit limited there, but this is a limitation of using the Servlet API being used for this. You'll have to spell out the specific repositories you wish to control access for.

A possible improvement would be a reimplementation of RDF4J Server (which is ancient) that can tie in with standard Spring Security features to give you better access control handling. Or alternatively, embed RDF4J repository management in your own REST server implementation.

[volkerjaenisch]

@jeenbroekstra
Thank you for the quick response.

Coming back to my initial claim:

So, is it correct to conclude, that there is no SPARQL-statement security in RDF4J?

All your information do not change the fundamental truth of this statement. RDF4J does not in itself has SPARQL-statement security.

You are right that one may secure its application utilizing the different endpoints that RDF4J offers for read/write Queries. But that was not the point of my claim.

A possible improvement would be a reimplementation of RDF4J Server (which is ancient) that can tie in with standard Spring Security features to give you better access control handling.

That is the spirit!

Cheers,
Volker

[abrokenjester]

All your information do not change the fundamental truth of this statement. RDF4J does not in itself has SPARQL-statement security.

No, I don't think that is correct (although I don't quite follow what "SPARQL-statement security" is supposed to mean exactly). As I explained, it's possible to configure, though admittedly somewhat cumbersome.

That is the spirit!

On a related note: we welcome contributions.

[abrokenjester]

@volkerjaenisch as completely unrelated aside: I have previously marked the original reply I made as an answer to your original question (it good to have that green tick because it makes it easier for other visitors to this forum with similar questions). What I'd like to ask is: can you try if you can "un-mark" it as such? You being the poster of the original question, I would expect that to be possible, but we are still figuring out the details of how Github Discussions works, exactly.

So just to be clear I'm not asking if you agree or disagree that this has answered your question, but purely to test if you can technically undo what I did as a moderator. Thanks :)

[seralf]

HI I'm struggle with a similar need (again!) in these days, so first of all thank @volkerjaenisch to open a thread on this, and exposing very well a typical scenario. And thank of course @jeenbroekstra as usual for explainations.

One of my concern in this direction is well explained by the phrase: "This can be easily achieved with the RDF4J/Tomcat security."
I'm not sure here how we can dynamically manage this way the creation of new repositories with their own scope, for specific users? Is there a way we can handle this avoiding tinkering with tomcat XML configurations? sorry in advance if it turns to be tomcat-related question.

Anyway, I think that in perspective it would be great to have a security/role module configuration that can be handled indipendently from tomcat... maybe a possible future development (#1502) may help in that direction?
I wonder if it would be possible to create a proxy module/repository access, in order to handle this part transparently to various repositories and endpoints (not exposed directly).

If anyone has suggestions in that direction, please share, I hope I was not too much off-topic here.

Alfredo

[seralf]

HI Volker thank you for other details.

The "readonly" access mentioned in the first point is clear, and in my team we used this approach in some different projects.

My concern is as you say on the tomcat-related issues that you explain very well.
The idea of editing XML and restart the repository could have some annoying effect for us, since we have in this case to put the triplestore on docker, so even handling the conf by external volumes, we should have a specific piepline to handle all this operations... I have to think about it.
Or one can handle them by "fixing" the security at a repository/user level, and federate some different repositories externally, under a read-only umbrella. It seems something a bit tricky.

I wonder if it would be possible to move the security on an internal specific module if there will be a self-executable distribution at some point, and meanwhile if one can achieve something similar by implmenting the logic at servlet/filter level, deploying a custom small component on tomcat itself. What do you think about? did you explore similar ideas?

thanks in advance

Alfredo

[barthanssens]

Another option perhaps (but not necessarily easier) is to create e.g. an AccessRestrictionSail and add role management there instead of tomcat etc

FWIW, OntoText uses Spring Security

[seralf]

this is a really good idea indeed, in perspective

[mielvds]

Hello all,

I would be very interested in having an access control layer in RDF4J somewhere. Our use cases typically include closing of particular repos/datasets/named graphs from unauthorized users who authenticate using LDAP. And by extension so are allowing certain users to give or revoke such access.

The AccessRestrictionSail that Bart suggests might be what we need. I imagine it being a combination of the recent contribution of Spring and the application of something like Apache Shiro or Spring Security. If somebody with sufficient knowledge of the RDF4J would design such component, I'd be happy to contribute.

[barthanssens]

FWIW: #3299