On 27/01/2023 20:29, Andy Seaborne wrote:
On 27/01/2023 16:33, Jonathan MERCIER wrote:
Dear dev & user of apache Jena,
I would like to know if we could to add an admin page on fuseki to
handle graph base access.
Actually I cn use apcha shiro embbed into jena fuseki in order to
authenticate through an LDAP connection but this do not do yet the
role mapping.
Ideally we would like this admin page on fuseki:
<https://graphdb.ontotext.com/documentation/10.1/user-management.html>
We could extend it by adding the possibility to register a bearer
token from a IAM service (keycloak, okta, mazone, azure ...)
Thus To reach this goal I take a look to jena source code and I do not
understand how jena-permission project works with jena-fuseki and
apache shiro.
One point:
Fuseki does not use jena-permissions, it uses jena-fuseki-access.
https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
Apache shiro dev show me this code:
<https://github.com/oktadev/okta-shiro-plugin/blob/1f22f79d2fdb36551e98fc7afd946c43e018c777/examples/jaxrs/src/main/resources/shiro.ini> which allow to use external bearer token.
So now how to wrap it all into jena fuseki ? :-)
I did some investigation (it's been a while since I looked at the code
....) - it's not as flexible as it could be.
The Graph Security Registry (access:registry) would be better in a
separate file not in the config.ttl, then it is easier to update it
through a web UI without needing to change the server config file.
That's access control per graph. It understands "security principal"
(aka user) for access authentication - not roles. If users have multiple
roles, there could be a piece of code to find the possible roles and use
"role" as the "access:user" ("users" being the wrong name now).
It would also be better if Fuseki had a soft restart options - build a
new DataAccessPointRegistry (it will use the same TDB databases), switch
over the DataAccessPointRegistry in a thread safe way.
Without soft restart, a load balancer can be used with 2+ servers behind
it - stop/start the servers one at a time.
---
At dayjob, we manage users and attributes (we have ABAC - labels on
triples, users have attributes that must match the label expressions in
a separate service. Roles are a subcase of attributes.
Fuseki talks to this separate service to get the attributes for the
authenticated user (tokens - AWS) and carries the attributes with the
request. User/attribute/role management happens in the separate service
which is not accessible from the external network that can access Fuseki.
The filtering is then using the same plugin-point that
jena-fuseki-access uses - it is filtering quads as they come from the
database before they pass into the SPARQL query execution engine.
Thanks
