This chapter describes how to configure subgraph access control.
Through the use of user-defined procedures and custom roles, an administrator may restrict a user’s access and subsequent actions to specified portions of the graph.
In other words, it is possible to configure access control at the level of a subgraph.
For example, a user can be allowed to read, but not write, nodes labelled with
Employee and relationships of type
The following sections describe the actions required to configure subgraph access control. The actions can be undertaken in any order.
The chapter describes the following:
Create the custom role, and, subsequently, assign the role to the relevant user(s).
CALL dbms.security.createRole('accounting') CALL dbms.security.addRoleToUser('accounting', 'billsmith')
In the LDAP scenario, the LDAP user group must be mapped to the custom role in Neo4j.
The procedure to read or write a portion of the data needs to be created, unless it is already available as an in-house or third-party library. Refer to Neo4j Developer Manual → User-defined procedures for a thorough description on creating and using user-defined procedures.
In standard use, procedures will be executed according to the same security rules as normal Cypher statements.
For example, a procedure with
mode=WRITE will be able to be executed by users assigned to any one of the roles
admin, whereas a user assigned only to the
reader role will not be allowed to execute the procedure.
The standard mode of usage can be overridden with the configuration options
These options allow specific roles to execute procedures they would otherwise be prevented from accessing.
dbms.security.procedures.default_allowed allows a role to execute any procedure that is not matched by the
dbms.security.procedures.roles setting provides more fine-grained control over procedures.
For example, setting
dbms.security.procedures.roles=apoc.convert.*:Converter;apoc.load.json.*:Converter,DataSource;apoc.trigger.add:TriggerHappy will have the following effects:
Converterwill be able to execute all procedures in the
DataSourcewill be able to execute procedures in the
TriggerHappywill be able to execute the specific procedure
The procedure’s role configuration is used to override the permissions given by the user’s roles. This will override the permission of the user with the mode of the procedure during the execution of the procedure. As a consequence, if the procedure attempts to execute database operations that are not included in its mode, it will fail with a 'permission denied' error regardless of the reason as to why the user was permitted to run the procedure.