[
https://issues.apache.org/jira/browse/JENA-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572612#comment-17572612
]
Vilnis Termanis commented on JENA-2339:
---------------------------------------
(Sorry for the delayed reply - busy week)
{quote}Has the PR been used "for real" or is it experimental?
{quote}
It's real in that I've tested it against our ACL use-cases (both from a
functionality & performance perspective). We're already using
{{jena-fuseki-access }} (i.e. a dataset layer with graph restrictions) but with
a static configuration. The purpose of raising this PR is that yes, we could
just go ahead and use the proposed feature internally but we think it might in
some form be a generic feature that might be of interest. (And of course
maintaining your own forks/side-modules has other downsides.)
Basically, if this were accepted, we'd most likely use it (and of course usual
workplace priorities aside), with the next available Jena release.
{quote}How big are the graphs? How many of them are there?
{quote}
As it stands, each (ACL-controlled) graph contains a few hundred triples and
there are thousands of graphs (of which a subset is matched with the "pragma").
FWIW, the overhead of dynamically generating the SecurityContext is, when
running a "no-op" query of "SELECT 1 {}" with a varying number of input graphs
in the pragma (Intel i7-8550U & 3.5GHz):
* ~600 graphs ~115ms
* ~1500 graphs ~162ms
* ~3k graphs ~240ms
* ~6k graphs ~400ms
(Note: Even with 6k graphs, in our use-case that is significantly faster than
filtering at a higher level by rewriting the query - and I don't mean FROM
CLAUSE addition.)
{quote}Do you need GRAPH/FROM NAMED for a query given that the named graphs are
used for security management?
{quote}
In addition to the security-managed graphs, there might be a (relatively small)
set of static (previously known) graphs the end user might want to reference.
The only other reason it might be useful to reference one of the ACL-allowed
graphs within a query is to say: "When the given conditions match a triple in
one of the graphs, return all triples within it".
(Note: We're using {{tdb:unionDefaultGraph true}} since for us the end-user
does not know in advance which graphs might be relevant to them - they're have
synthetic IDs.)
{quote}Surely an approach is to improve this when passed in FROM/FROM NAME e.g.
Graph sets. (a URI that gets expanded in {{{}DynamicDatasets{}}}). It is useful
outside the security usage.
{quote}
I agree it could be useful outside of security. I don't however quite follow
the FROM suggestion. Are you proposing this the [alternative
solution|https://github.com/vtermanis/jena/blob/dynamic-graph-restriction-extension/MOVE_ME_DynamicACL_notes.md#alternatives]
or re-writing the incoming query and adding a bunch of FROM/FROM NAMED
clauses? (The performance for this [was a lot
lower|https://markmail.org/message/zoi2hwntyfjuy7er] when I tried it with 100s
rather than 1000s of graphs.)
> Proposal: Extension to jena-fuseki-access to support dynamic ACL
> ----------------------------------------------------------------
>
> Key: JENA-2339
> URL: https://issues.apache.org/jira/browse/JENA-2339
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
> Affects Versions: Jena 4.5.0
> Reporter: Vilnis Termanis
> Priority: Major
>
> In summary: Extend jena-fuseki-access to allow the visible-graph list be
> specified at query time rather than just configuration-time, thus allowing
> services which rely on Fuseki to provide the visible graph list dynamically,
> based on external user/role/identity.
> In detail:
> See pull request [https://github.com/apache/jena/pull/1441] and [description
> of the
> what/why/how|https://github.com/vtermanis/jena/blob/dynamic-graph-restriction-extension/MOVE_ME_DynamicACL_notes.md].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
