Thanks Andy,
I tried to take a look to the code but I encounter some environnement
configuration problem I will open a separate thread.
To my understanding, I would use the logic below (but I do not have
your insight)
1. fuseki start
2. check if shiro conf file exist in standard location (on linux it is
File Hierarchy standard, so for an user ~/.config/fuseki)
2.a. if true load the file
2.b if false use the one provided by ressources and sotre it to the
given location in order to bootstrap
3. the main page (index) check session
3.a if session exist go to list of dataset which are at least allowed
authorized to read
3.b if not -> classical login form with 2 input text user/password
Le lun., janv. 30 2023 at 21:04:57 +0000, Andy Seaborne
<[email protected]> a écrit :
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
