Custom Security extension point options

[diane_griffith]

Curious if anyone has rolled a custom security approach with Neo4j that is more permission based (versus role) to protect access to nodes and edges?

We have a need to protect access of the sub-graph nodes or edges that get returned with a query.

Wondering if anyone has suggestions of good extension points for that.

Basically if the user making the query through a java application should not have access to the data (the node or edge depending on where the permission is tagged) then that data should be pruned or traversal stopped down that part of the tree).

Suggestions of areas to try are appreciated and curious if anyone else has tried to do this. We are trying to determine if augmenting the query is a valid option. It was unclear if there was an HTTP API extension point that could help. We have been looking at can we dynamically tag the querying user as a role to keep traversing but are hoping there are other options. Our users would not be stored within Neo4j, I get there are classes we can write to hook to our authentication and authorization provider.

Would love to hear suggestions of things to check out.

Diane

[albertodelazzar]

Hi Diane,
If you want to write your own auth provider you can take a look at this article.
Your custom auth plugin must implement the AuthPlugin interface.

The access is role-based, so you have a user with a given profile and this profile will have some permissions.
If you want to restrict the access the "official" way is through a Java Procedure as explained here. With 3.5 version you can also use the property-level security feature.

You can also put the "permission logic" on your model that is adding labels to your nodes but it depends on how complex your permissions are and how this can impact the queries. A similar solution is using a meta-graph that represents your users/roles/permissions tree and attach it to your "real" graph. As I said before, this could impact your queries and this meta-structure should be also easy to change in the future without too much pain.

The third option could be to find a hook in the core API(s) that is, find the right class along the flow of your query execution (from the cypher runtime to the transaction) and check what can be seen by the user according to his permissions.

In the next months, we will work on this topic for an important project where security is one of the biggest issues. Maybe I can give you some tips as soon as we will start working on it.

Regards

Alberto