Skip to content

Jena ACL layer#588

Draft
amrc-benmorrow wants to merge 8 commits intomainfrom
bmz/fuseki
Draft

Jena ACL layer#588
amrc-benmorrow wants to merge 8 commits intomainfrom
bmz/fuseki

Conversation

@amrc-benmorrow
Copy link
Contributor

This is a WIP started for the Data Access project (24/25).

Apache Jena Fuseki is an RDF triplestore. This PR includes Fuseki as part of ACS with a (currently minimal) triple-level ACL layer.

For now this just extracts the Basic auth header directly and ignores
the password. This wants integrating with Jetty or something eventually
but it doesn't matter for now.
This is very crude at present. The basic structure is that an ACL grant
is a triple with predicate `acl:readTriple`; the object of this is an
acl:ShexCondition identifying triples the subject may access.
(Annoyingly ShEx TripleConstraints are effectively constraints on a
node rather than on a triple as such).

These `readTriple` triples must be present in the default graph of the
dataset; for now I am ignoring other graphs, but if we use them it will
most likely be for hypothetical or otherwise 'quoted' triples so we
don't want them to be active permission grants.

A ShexCondition has three properties, `acl:subject`, `acl:predicate` and
`acl:object`, all ShEx expresssions. For now these are limited to:

    - value NodeConstraints
    - forwards TripleConstraints with cardinality 1

Since the Jena ShEx library won't (yet) compile ShEx expressions from
RDF, only from JSON or ShExC, we need to traverse the graph and build
the expressions by hand.

Our DatasetGraph builds the ACL for a principal, for now from scratch on
every request. This means collating all the Shapes, combining them into
a Schema, and recording a set of triples representing the ShexCondition
objects. It should be possible to use these to evaluate the ACLs.
It's cleaner this way.
Convert the FPShapeBuilder into a builder class for FPShapeEvaluator;
this now holds the final ShexSchema. This removes the
Optional<ShexSchema> which is obviously a good thing.

At the moment I build the FPShapeEvaluator in get(); it doesn't feel
quite right building it in the constructor. This means another Optional,
unfortunately, since we're changing state again. A proper implementation
would use change-notify and maintain a single schema with all the shapes
in the graph in any case.

Implement find() on top of stream(), instead of the other way round. The
Iterator classes seem to be extremely limited.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant