Privileges to read subset of label

Hi,
I have a scenario where I have nodes with a label, say Label1, and they are all representing the same thing. However, I dont want all users to be able to query/read/traverse all nodes with Label1.
My first thought was to add a label to these nodes, say SubLabelX, deny users to match/read/traverse nodes of Label1, and allow them to match/read/traverse nodes with SubLabelX.

However this seems to work out to not allow them to do anything, which is totally logical.
So my question is: Does the access model for neo4j 4.0 allow for letting different user groups get access to different subsets of nodes with a given label somehow, or is it all nodes with a label or none?

Thanks!

Did you look into the (new for 4.x) access control features?
Haven't worked with it myself yet but from what I get from glancing at the documentation there are several scenarios which might work for your use-case?

https://neo4j.com/docs/operations-manual/current/authentication-authorization/access-control/

yeah, that is what i have looked at a bit, but i cant figure out how to make a subset of nodes readable to a group.. seems to be all or nothing in terms of existence of the nodes.. restricting access to subsets of properties works fine..

Hi Kaptenh,

It seems to be working as expected. Following is what i successfully tried :slight_smile:

Connect to system database as neo4j/admin user and run following commands

Create database Movie1

CREATE USER danny SET PASSWORD 'all4one' CHANGE NOT REQUIRED SET STATUS ACTIVE;
CREATE ROLE restricted_movie
grant role restricted_movie to danny;

:use Movie1

CREATE (n:HP:HPE {name:"Mike"})
CREATE (n:HP:MFOCUS {name:"Jassi"})

match(n:HPE) return n;
Only Mike node will be returned

match(n:HP) return n;
Both Mike & Jassi nodes will be returned

:use system
grant TRAVERSE on GRAPH movie1 NODES HPE to restricted_movie

:server disconnect
Connect as user danny
match(n:HPE) return n;
Only node with Mike's id will be returned

match(n:HP) return n;
Only node with Mike's id will be returned

BUT........
match(n:MFOCUS) return n;
This will not return any row.

Label HPE worked because we had given grant on this Label and Label HP work because it is an alternative label for HPE and it has returned only one row instead on 2 (as neo4j user it returned 2)

I believe this is a expected behavior and yes groups can be formed for different access privileges.

Hi,
yes, that is an expected behaviour and it does answer the original question, but reading the last answer made me think harder.
As dannys example show, one need to have privileges to access all the labels of a node to be able to see it. What I would really like in my application is that it is enough to be allowed to see one of the labels. OR the privileges instead of AND.. perhaps there is a way around it..

Thanks for the answers!

Is there any way to force an OR behaviour on access control to nodes with multiple labels?
Maybe by writing some sort of plugin or such?

We have shared resources, that not everyone should have access to, and an AND on privileges leads to an exponential increase of user roles..

Lets pretend we have Patients and Doctors.. not all Doctors should be able to see information about patients, but we still want the Patient label on the nodes, to be able to write consistent queries.
So an admin should be allowed to do everything to the Patient label.
DrA, and DrB have patients, so the patients of DrA could have some label that DrA have access to, and the same for DrB.
This could in theory be solved by letting all doctors have access to all patients, but all patients also have a label specifiying which doctor it sees.
Now, for some not too unreasonable reason, one patient sees both DrA and DrB so both should be able to access the information. Only way (that I can think of) is to make a new group allowed access to a new label DrA_DrB.. which leads to ridiculousness in the long run.

I need to solve this access control problem, either within Neo, or outside, and would prefer to do it within the Neo access control if possible..

Thanks, and keep up the good work on this really good product :slight_smile: