Spike: find out if we can secure our KG with ACLs

[jachro]

As a Renku user, I don't want metadata of my or my organisation private/internal projects to be queryable by users not having access to them.

Acceptance criteria:

• find out if Jena's ACLs allow achieving the non-queryable goal in a presence of user's token or credentials when running a query;

A start point can be this: https://jena.apache.org/documentation/fuseki2/data-access-control

[jachro]

The spike findings:

• It looks like the standard Jena way of doing data security is to define users access rights per graph. Effectively, what you do is you define which user(s) can access which graph(s). The main problem with the approach from our perspective is that you configure the access rights in a config file which is read during Fuseki start so it's not very dynamic and cannot be changed once the server is started. More details can be found here: https://jena.apache.org/documentation/fuseki2/data-access-control#graph-acl
• There's also an alternative solution which involves development of some custom plugins. It's described here. As part of this issue, I tried to implement these plugins and here are the findings/observations:
  • Jena allows plugging-in custom security realm which replaces the default mechanism of finding both authorization and authentication data. As part of the issue, I implemented a naive version of a Renku realm which gives access to the Jena API for two privileged users admin and renku as well as users which are authenticated in some external system (GitLab). The credentials of the privileged users are read from the shiro.ini config file as it's being done now. The approach for the external service users would be that they will be introducing themselves to the Jena API with an external service token (given as password; shiro in the version used by Jena does not allow using bearer tokens) which then the realm would use to authenticate against the external service and fetch projects they are authorized to. The projects potentially can simply serve as users roles.
  • There's a possibility of adding a custom SecutiryEvaluator which is used for all the actions on a defined dataset. The Evaluator can use the authorization data from the custom realm mentioned above to verify user permissions to triples and graphs. The simple implementation I developed as part of this issue simply checks if a user performing an action on a dataset has access to project-related triples based on the roles fetched from the external service.
  • Due to the plugins mentioned above, it would be required to build our own Jena docker image which might not be a bad idea considering we're plugging-in some custom files to the image even now.
  • The way the results get influenced by the permission mechanism is:
  • For a user having no rights to see certain projects executing the following query

PREFIX schema: <http://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?dsId ?prjId
WHERE {
  ?dsId rdf:type <http://schema.org/Dataset>;
        schema:isPartOf ?prjId
}

the result set will contain only datasets from either public projects or projects the user has access to.

*

• • For a user who cannot be authenticated to the external service, the result set will be empty.
  • For a user who is authenticated and authorised to certain projects executing query:

PREFIX schema: <http://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?dsId
WHERE {
  ?dsId rdf:type <http://schema.org/Dataset>
}

the result set will contain info also about datasets linked to projects the user has no access to. So there's still quite some responsibility on the developers who build SPARQL queries. For the time being not so sure how to overcome that and not making the Evaluator running some additional querries which could have some detrimental effect on the KG performance.

• Further work:
  • Find out how the dataset config.ttl should look like considering the requirements for the custom plugins and settings we've already got for the Lucene indices.
  • Find out how to build the Docker image which would involve building the custom plugins as well as keeping the functionality/settings we inject to the current standard image.
  • Build a GitLab authorizing/authentication data fetching mechanism.
  • Introduce some caching mechanism for users' authentication data.
  • Productionise the plugin's code.
• All the work can be found in the jena module of the renku-graph repo (jena-security branch).

[rokroskar]

is the answer yes? or 42? 🤖

[jachro]

We decided a non-Jena specific option would work better for us. So we ended up with the service level verification based on the GitLab and Triples Store members.