Can I use Native User Role to limit access to a user's 'own' data?

Is there a built-in way to use Native User Roles to limit a user's access to only his/her own nodes & relationships? Does neo4j maintain any record of which user created a node, or would such ownership have to be explicitly built into the model?

If there is not a built-in ownership mechanism, I see that in the operations manual-- 8.4.2. Custom roles--we can add our own custom roles and add custom procedures to them. Has anyone used this method for giving only a user access to his/her own creations (while blocking others' access)?

1 Like

Bumping this thread up as I'm very much interested in this as well. I need to display exclusively logged-in users's managed items in his/her dashboard. These items are, of course, nodes in Neo4j but not necessarily the ones the user created himself.

Currently our role and security features don't cover these kind of cases, you would have to enforce these in the queries themselves, or in filtering before the results are returned to the user.

That said, improving on the richness of our security and visibility features became high priority awhile back, so you're very likely to see improvements here in our next major release near the end of the year which may better address these cases.

1 Like

Thanks Andrew. I guess in the end it will likely be a graph solution, whether implemented under the hood or explicitly.

Is there any progress on this topic since July? Either in released form that this issue might link to, or information about what is in store for the future? @andrew.bowman

Hello, yes, we've had a few 4.0 milestone releases as we march toward the GA release around the turn of the year, and some of the applicable features are multi database and schema based security.

However, at present these new features are not owner-based. We don't have automatic tagging of created nodes and relationships for the logged in user, that would have to be done using something like a trigger via APOC or transaction listeners.

With multi-database, it could be possible to have a separate database per role (though this would require some setup and some way to provision the new database for a role, and grant the appropriate permissions/role for the user), and the databases would be isolated from each other, but this is only meant to scale to 100's of databases at most, so if the userbase you need to support is greater than that then this wouldn't be the way to go.

With schema based security you could enforce various privileges such that roles could only read/write/traverse nodes with specific labels/relationship-types, and I think there may be some work in the backlog to enhance these such that certain property values can be used as a security filter (so when this does get implemented, you could have read restrictions for a role so they can only read nodes where property x = y). This in combination with the trigger for adding a property to a node on creation sounds like it's the best match for what you're looking for, but it will require waiting for that enhanced security feature on the property values.

Also note that we're talking roles here, not individual users. The primary use case we're tackling on the security side right now is based on roles, not on individual users.