JENA-2339
PR#1441
https://github.com/vtermanis/jena/blob/dynamic-graph-restriction-extension/MOVE_ME_DynamicACL_notes.md
tl;dr:
It is a different role for Fuseki.
Fuseki execute the security but the setup and control is from a trusted
external server on the request execution path.
It assumes certain deployment environments to be safe.
My feeling is that we should make Fuseki configurable enough so that a
downstream 3rd party can add their security solution that is suitable
for their environment. But we should not incorporate a particular
security solution that relies on the deployment environment.
----
I've asked for more information about the claim on a performance
motivator and some other background information.
The usage patterns are not yet clear. The data is described as "a one
graph per handful of subjects and their properties" and "100s of
graphs". What the queries are is unstated.
There is no characterisation of the queries being made. If we are
talking about overheads, the cases of a few big queries and many small
queries are different.
The scale looks small (less than a million triples of triples -
approximating as 100 graphs * 1000 triples). That makes the point about
access to TDB hooks a bit redundant.
There is are distinguished users. A request from one of these users
causes the set of visible graphs to be read from a comment at the start
of the query text in the request.
The use of large numbers of small named graphs to manage security
settings looks to me like triple-level security. I have already
mentioned work "FMod_ABAC": (£job related) awhile back (2/Jan/2022). It
is triple level attribute-based security.
Concern 1:
This by passes Fuseki-provided security and puts the control function
outside the Fuseki server in a separate server that is not part of Jena.
It will only be secure if deployed in a constrained network environment.
This is not secure except when run in a certain way and, personally, I
don't want to have to deal with a CVE because of that. CVE handling is
time consuming.
I don't see why it is using jena-access (the named graph security
feature) except for the filtering on TDB. It is creating a dynamic
dataset for the query.
Concern 2: How does update fit into the picture? (GSP is not supported).
Concern 3: It looks like a specific solution for a specific scenario.
Will it get uptake by the wide Jena user community?
Concern 4: Is there long-term support and maintenance for the feature?
(e.g. 5y+)
How do we respond to users@ message about it? Is it experimental code or
has it been used for real? Is the feature set stable?
Opinion: it is not unreasonable to provide support for this kind of
customization of Fuseki.
An extension can then provide whatever security is needed for the
situation and it is the Fuseki user/operator making the decisions about
what is acceptable security and what isn't.
Fuseki has ways to add custom processors and this seems the way to
provide an alternative way to make queries.
Putting it in the distribution codebase is a big step for the project.
At the very least, it needs to be mature and likely to be used.
Background: Currently jena-access is in Fuseki main. It is not optional
because it predates Fuseki modules.
Andy
