I **guess** we would need an endpoint in Jena to return the authenticated user
data (or an error or empty result if not authenticated), if this endpoint does
not exist already (either provided by Jena, or Shiro directly?).
Then in the current UI, we would need to create the JS code to store securely
the info (depends on the data, could be a token in local storage, or an
encrypted cookie).
Finally, the endpoints in Jena would have to verify i) is auth enabled? and ii)
if it is, then is the user authentication token/data provided in the request?
YES -> serve data (maybe tailored for the user profile/roles/permissions), NO
-> reject.
But I don't know every part involved in the Jena auth & frontend/backend, so it
could be wrong or missing some steps.
Cheers
Bruno
On Friday, 16 October 2020, 8:48:24 pm NZDT, Kruiger, J.F. (Han)
<[email protected]> wrote:
Hi Andy,
Thanks for the answer. I understand that this is not something Apache Jena
currently offers.
If anyone has insight in what needs to be done to support/achieve this, I'm all
ears!
Best,
Han
-----Original Message-----
From: Andy Seaborne <[email protected]>
Sent: donderdag 15 oktober 2020 17:25
To: [email protected]
Subject: Re: Fuseki Web UI does not consider Dataset Level Access Control Lists
Hi Han,
The access control does not connect to the UI so you can't make datasets
invisible. Sorry about that.
Andy
On 14/10/2020 08:28, Kruiger, J.F. (Han) wrote:
> It appears my attachments didn't come through.
>
> config.ttl:
> ```
> @prefix : <#> .
> @prefix fuseki: <http://jena.apache.org/fuseki#> .
> @prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
>
> <#service1> a fuseki:Service ;
> fuseki:name "dataset1" ;
> fuseki:allowedUsers "user1" ;
> fuseki:endpoint [
> fuseki:operation fuseki:query ;
> fuseki:name "sparql" ;
> ] ;
> fuseki:dataset [
> a ja:MemoryDataset
> ] .
>
> <#service2> a fuseki:Service ;
> fuseki:name "dataset2" ;
> fuseki:allowedUsers "user2" ;
> fuseki:endpoint [
> fuseki:operation fuseki:query ;
> fuseki:name "sparql" ;
> ] ;
> fuseki:dataset [
> a ja:MemoryDataset
> ] .
> ```
>
> shiro.ini:
> ```
> [main]
> # Development
> ssl.enabled = false
>
> plainMatcher=org.apache.shiro.authc.credential.SimpleCredentialsMatche
> r #iniRealm=org.apache.shiro.realm.text.IniRealm
> iniRealm.credentialsMatcher = $plainMatcher
>
> localhostFilter=org.apache.jena.fuseki.authz.LocalhostFilter
>
> [users]
> # Implicitly adds "iniRealm = org.apache.shiro.realm.text.IniRealm"
> user1=pw
> user2=pw
>
> [roles]
>
> [urls]
> ## Control functions open to anyone
> /$/status = anon
> /$/ping = anon
> /$/metrics = anon
>
> /$/** = authcBasic,user[admin]
>
> # Everything else
> /**=anon
> ```
>
> Cheers,
> Han
>
> -----Original Message-----
> From: Kruiger, J.F. (Han) <[email protected]>
> Sent: woensdag 14 oktober 2020 09:24
> To: [email protected]
> Subject: Fuseki Web UI does not consider Dataset Level Access Control
> Lists
>
> Hi there,
>
> When using the Dataset Level Access Control Lists
> (https://jena.apache.org/documentation/fuseki2/data-access-control#dataset-acl)
> to disallow a user from accessing a dataset, I expect the dataset in
> question to *not* be listed in the list of datasets that that user sees in
> the web UI.
>
> However, when I do the following:
>
> - Use the attached configuration and shiro.ini (user1 has access to
> only dataset1, user2 has access to only dataset2)
> - Visit localhost:3030 and log in as user1
>
> I can still see dataset2 in the list, even though user1 cannot access its
> services.
>
> My questions are the following:
>
> - Is this the intended behavior?
> - How do I make it so that the web UI only shows the accessible datasets for
> the logged in user?
>
> Thanks in advance!
>
> Best,
> Han
> This message may contain information that is not intended for you. If you are
> not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use it
> and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
