Role-Based Access Control (RBAC) in Neo4j

© 2022 Neo4j, Inc. All rights reserved.
Role Based Access Controls
(RBAC) in Neo4j
Jeff Tallman
jeff.tallman@neo4j.com
Field Engineer/Pre-Sales Engineering

2
Role Based Access Controls (RBAC)
• Understand the levels of RBAC supported
• RBAC basics for data access
• RBAC roles for separation of duties (DBA vs. SSO)
• RBAC roles for developers & GDS execution

RBAC Privileges
Privileges operate only on roles - not user/logins
• Can only be granted to roles - you can’t grant a privilege to a specific user name
Changes take place immediately
• Privileges are not cached - so no need to disconnect/reconnect or “grant all to null” to flush
cache as with other DBMS’s
Roles & Privileges are stored in the system database
• Make sure you back it up
• If copying a database to a new system, make sure you backup with --include_metadata option
Databases as containers
• One concept that may be difficult for users of MS SQL, et al to grasp is that each database in
Neo4j is a completely separate entity
• For example, query processing takes place within the context of a database
◦ Which is why cross-database queries are not supported (except via Fabric)
• However, roles and permissions granted to roles (including graph-privileges) are stored in
system

Native Roles
PUBLIC
• The default role. Every new user or role will inherit
this role.
• Access to the default/home database.
• Allows executing procedures & user-defined
functions with the users own privileges.
reader
• A typical read-only role.
editor
• A regular user with read/write access to the
database, write access limited to creating and
changing existing properties,node labels and
relationships.
publisher
• A user traverse,read and write on the data graph
Architect
• A user who can manage indexes and constraints
admin
• A superuser, database administrator
4
https://neo4j.com/docs/operations-manual/current/authentication-authorization/built-in-roles/
(matrix below from docs is generally correct
but not exactly precise - see later slides)

Privilege Categories
• Roles
◦ Typical RBAC roles - user defined or system predefined
• dbms-privilege
◦ Privileges that span the database instance and are not able to be restricted to a single database or role
• database-privilege
◦ Admin or access privileges than can be assigned to a particular database at the database level
• graph-privilege
◦ Privileges are that can be granted within a single database

General Syntax
GRANT
• Allows access
DENY
• Blocks access
• Take precedence over all other granted privileges that the user
may have no matter what other roles may have the privilege
• In other words, denying any privilege to PUBLIC …..denies it
for everyone no matter if admin or not…or if granted privilege
on a different role….
o So be very, very careful if denying a privilege to PUBLIC
REVOKE
• Removes a previously granted or denied privilege
Graph = Database
• HOME GRAPH
o The user’s “home database”
• GRAPH <graphname>[,<graphname>[, …]]
o The listed database or databases
ENTITY
• NODES
• RELATIONSHIPS
• ELEMENTS - both NODES & RELATIONSHIPS
<role>[, <role>[, …]]
• A list of user defined or predefined system roles
[GRANT|DENY] graph-privilege ({proplist})
ON {HOME GRAPH | GRAPH[S] {* | name[, ...]}}
[entity] TO role[, ...]
REVOKE ([GRANT|DENY]) graph-privilege ({proplist})
ON {HOME GRAPH | GRAPH[S] {* | name[, ...]}}
[entity] FROM role[, ...]
DENY READ { taxPayerID } ON GRAPH protegrity
NODES Customer TO reader
;
SHOW PRIVILEGES [YIELD <col list> | *];
SHOW ROLE <rolename> PRIVILEGES [AS COMMANDS];

DBMS Level Privileges Hierarchy

Database Privilege Hierarchy

Graph Privileges and Hierarchy

Separation of Duties - DBMS Management
DBA’s (dba_role)
• Manage and monitor the DBMS
• Manage transactions (kill run away queries)
• Do not manage database schema or data itself other
than perform backups/restores
Operations DBA (operations_role)
• Monitor the DBMS
SSO (sso_role)
• Manage logins/users
• Manage system roles
Database Admin (dbadmin_role)
• Manage access to a database
• Manage permissions within a database
• Manage roles for a database
• Note that all of the above can only be controlled at the
DBMS level vs. individual database
o So granting this privilege allows the role to allow access
and manage roles for other databases as well…
o ….if undesirable, then SSO has to be involved for any of
these operations.
(admin)
Dba_role
Oper_role
SSO
dbamdin
All DBMS Privileges 
Database Management  
Create | Drop | Alter database   ?
Stop | Start database   
Set database access   ?
Exec Admin Procedure   ?
Show transaction    db
Terminate transaction    db
Transaction management    db
Privilege management   ?
Assign privilege   ?
Remove privilege   ?
Show privilege   ?

Separation of Duties - Roles & Users
DBA’s (dba_role)
• Manage and monitor the DBMS
• Do not manage database schema or data
itself other than perform backups/restores
Operations DBA (operations_role)
• Monitor the DBMS
SSO (sso_role)
• Manage logins/users
Developer & GDS Users (developer_role)
• Can create schema components
• Able to kill their own queries
(admin)
Dba_role
Oper_role
SSO
dbamdin
Role management   ?
Create | Drop | Rename role   ?
Assign | Remove role   ?
Show role   ?
User management  
Create | Drop | Rename | Alter user  
Set passwords  
Set user home database  
Set user status  
Show user  
Impersonate  ? ?

Separation of Duties - Database Schema
System predefined roles
• Can access any database
• admin role can do anything
• architect and publisher can do anything
schema-wise except grant access
Developers (developer_role)
GDS Users (gds_role)
• Able to create new labels & relationship
types
• Able to create new properties
• May need to be able to create indexes
architect
publisher
editor
dbadmin
Developer
GDS
User
App
User
Sched
Job
CREATE INDEX      ?
DROP INDEX      ?
SHOW INDEX      ?
INDEX MANAGEMENT     
CREATE CONSTRAINT     ?
DROP CONSTRAINT     ?
SHOW CONSTRAINT     ?
CONSTRAINT MANAGEMENT    
CREATE NEW LABEL      ?
CREATE NEW RELATIONSHIP TYPE      ?
CREATE NEW PROPERTY      ?
NAME MANAGEMENT      ?
ALL DATABASE PRIVILEGES  
ACCESS ON DATABASE * (all databases)   
(lacks access priv)

architect
publisher
editor
dbadmin
Developer
GDS
User
App
User
Sched
Job
TRAVERSE        
READ        
MATCH        
CREATE        
DELETE       ? ?
SET LABEL       ? ?
REMOVE LABEL       ? ?
SET PROPERTY        
MERGE        
WRITE       ? ?
ALL GRAPH PRIVILEGES   
EXECUTE PROCEDURE
EXECUTE BOOSTED PROCEDURE ? ? ? ?
EXECUTE USER DEFINED FUNC
EXEC BOOSTED UDF ? ? ? ?
Separation of Duties - Graph Privileges
Developers (developer_role)
GDS Users (gds_role)
• Able to create new labels & relationship
types
• Able to create new properties
• May need to be able to create indexes
Application User (<user defined roles +
PUBLIC>)
• Read/Write or Read-Only as necessary
• Can’t create schema components
< ----------------------- (PUBLIC) ----------------------- >
< ----------------------- (PUBLIC) ----------------------- >

Creating a developer role (sample)
CREATE ROLE developer_role;
GRANT INDEX MANAGEMENT ON DATABASES * TO developer_role;
GRANT CONSTRAINT MANAGEMENT ON DATABASES * TO developer_role;
GRANT NAME MANAGEMENT ON DATABASES * TO developer_role;
//GRANT ALL PRIVILEGES ON DATABASES * TO developer_role;
GRANT ALL GRAPH PRIVILEGES ON GRAPHS * TO developer_role
This would be a mistake!

Impersonation: A key aspect of RBAC
Two critical reasons for impersonation
• Enterprise systems with middle tier components or
microservices often need to act on the behalf of
other logins
o Disconnecting/Reconnecting at every user change is
error prone and excessive overhead
• Testing or debugging security controls is almost
impossible unless you can mimic other users
Currently supported ONLY in language API’s only
• No cypher equivalent to SQL’s “set session
authorization”
• In the API, it is part of the session configuration
• Sooo…you can not test impersonation/security via
cypher-shell or browser
Grant to impersonate specific users
• If you grant permission to * …..user can become
“neo4j” with admin role
• …or may end up getting elevated privileges
GRANT IMPERSONATE [(*)]
ON DBMS
TO role[, ...]
GRANT IMPERSONATE (user[, ...])
ON DBMS
TO role[, ...]

Separation of Duties - DBA
Creates DBMS DBA role
• Can create/drop/alter databases
• Can execute amin procedures
• Can execute boosted procedures that are named
dbms.*
Creates DBMS Oper role
• Complements DBA role
• Can be assigned to operations staff that we don’t
want to be able to create/drop databases
• Can stop/start any database
• Can see/kill transactions from any user
Creates a DBMS DBA user
• Has both dba_role and oper_role
• Does not have access to any database except
system
o Access to system is due to fact it is user’s “home
database”
o DBA can see database exists, but attempts to use
the database will fail
• As a result, cannot see any user data
:use system;
CREATE ROLE dba_role IF NOT EXISTS;
GRANT CREATE DATABASE ON DBMS TO dba_role;
GRANT DROP DATABASE ON DBMS TO dba_role;
GRANT ALTER DATABASE ON DBMS TO dba_role;
GRANT EXECUTE ADMIN PROCEDURES ON DBMS to dba_role;
GRANT EXECUTE BOOSTED PROCEDURES dbms.* ON DBMS to dba_role;
CREATE ROLE oper_role IF NOT EXISTS;
GRANT STOP ON DATABASE * TO oper_role;
GRANT START ON DATABASE * TO oper_role;
GRANT TRANSACTION MANAGEMENT ON DATABASE * TO oper_role;
CREATE USER ima_dba IF NOT EXISTS
SET PLAINTEXT PASSWORD "ima_dba"
SET PASSWORD CHANGE NOT REQUIRED
SET STATUS ACTIVE
SET HOME DATABASE system
;
GRANT ROLE dba_role TO ima_dba;
GRANT ROLE oper_role TO ima_dba;

Separation of Duties - SSO
Creates DBMS SSO role
• Can manage users
• Can manage roles
• Can manage privileges
• Can control access to databases
There is a security hole/exposure w/ Role Mgmt
• Problem is Neo4j does not allow for role exclusion
o E.g. if you have role A, you cannot have role B
• Consequently, an SSO role user can grant
themselves DBA role….or dbadmin_role (next) and
do things they shouldn’t
• It would be automatically logged into security.log
o So as long as the SSO didn’t have the ability to write
to that log (e.g. not neo4j user), they couldn’t hide
what they did
o No real workaround - anyone with “ASSIGN ROLE”
permission can become whomever they want
:use system;
CREATE ROLE sso_role IF NOT EXISTS;
GRANT SET DATABASE ACCESS ON DBMS TO sso_role;
GRANT PRIVILEGE MANAGEMENT ON DBMS TO sso_role;
GRANT USER MANAGEMENT ON DBMS TO sso_role;
GRANT ROLE MANAGEMENT ON DBMS TO sso_role;
CREATE USER ima_sso IF NOT EXISTS
SET PLAINTEXT PASSWORD "ima_sso"
SET PASSWORD CHANGE NOT REQUIRED
SET STATUS ACTIVE
SET HOME DATABASE system
;
GRANT ROLE sso_role TO ima_sso;

Separation of Duties - DBAdmin
Creates DBAdmin role
• Can do anything within the specified database
• Can modify schema
o create indexes/constraints
o Create new labels, relationship types, property
names
• Can read/write data
• Can see/kill user processes for this database only
There are several security holes/exposures
• Problem is Neo4j does role/privilege/access
management at a per database level
• Which then also exposes the role management
hole
• Workarounds
o Again, it is audited in the security.log
o Don’t grant dbadmins this permission - or grant only
for a short time (when designing security layer)
• Otherwise restrict to sso_role
:use system;
CREATE ROLE custdb_dbadmin_role IF NOT EXISTS;
GRANT ALL DATABASE PRIVILEGES ON DATABASE custdb
TO custdb_dbadmin_role;
GRANT ALL GRAPH PRIVILEGES ON GRAPHS custdb
GRANT TRANSACTION MANAGEMENT ON DATABASE custdb
// We will assume this is not multi-tenancy, therefore we
// will trust individual dbadmins to be able to create roles
// and assign privileges - but not be able to manage users
GRANT SET DATABASE ACCESS ON DBMS TO custdb_dbadmin_role;
GRANT PRIVILEGE MANAGEMENT ON DBMS TO custdb_dbadmin_role;
GRANT ROLE MANAGEMENT ON DBMS TO custdb_dbadmin_role;

19
Thank you!
Contact us at
sales@neo4j.com

Role-Based Access Control (RBAC) in Neo4j

Recommended

More Related Content

What's hot (20)

Similar to Role-Based Access Control (RBAC) in Neo4j (20)

More from Neo4j (20)

Recently uploaded (20)

Role-Based Access Control (RBAC) in Neo4j