On 16/10/2020 11:01, Rob Vesse wrote:
Ideally you do this entirely on the API implementation side i.e. the server so
that the UI doesn't need any changes. The browser will already be
communicating the credentials the user provided to the server implicitly when
authc is enabled (e.g. via the browser login prompt).
If the UI is displaying a dataset that is explicitly forbidden to the user
should the server not already be not returning that dataset via whatever API
call the UI uses to list datasets? i.e. is this not a bug in the Dataset ACL
implementation rather than the UI?
Yes - specifically two places:
1/ The admin code, the server side of the UI functionality, which does
the listing of datasets, predates the dataset and triples ACL (maybe
other operations reveal it as well as well).
("admin" has become a misnomer - it combines "admin" functionality and
UI support functionality)
2/ The dispatch of request to dataset which reveals the dataset
existence because it is 403, not 404.
The dataset ACL code executes after HTTP request dispatch (it has to
find the ACL!) and I guess it says "yes" or 403 which is an information
leak.
Andy
Rob
On 16/10/2020, 09:09, "Bruno P. Kinoshita" <[email protected]> wrote:
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.
>
