By Igor Borojevic, Director of Product Management | April 5, 2017
In Neo4j 3.1 Enterprise Edition, we introduced a new role-based access control framework for user and application access to the database. The framework enables system administrators to manage permissions and ensure that authenticated users and applications can perform only authorized actions on data graph stored in Neo4j.
In this series on database security and access control, we’ll explore all of the different facets and features available in Neo4j Enterprise Edition to keep your data secure. Last week, we looked at role-based access control in Neo4j.
This week, we’ll take a closer look at administering both database security and access control for native users of Neo4j Enterprise Edition.
Internal authentication means that user names and their passwords are managed inside Neo4j. We call this built-in functionality native users. Another way of controlling authentication is through external security software such as Active Directory accessed via the built-in LDAP connector.
For administering native users, Neo4j offers additional actions for an admin:
- View all users and roles
- Create and Delete any other user
- Assign and Remove role from user
- Create and Delete custom-defined role
- Suspend and Activate any other user
- Change password for any user (cannot be an empty string or an existing password)
- Admin can suspend or delete any other user (including other admins), but not itself.
- Deleting a user terminates all of the user’s running queries and sessions.
- All queries currently running for the deleted user are rolled back.
- The user will no longer be able to log back in (until re-activated by admin if suspended).
- There is no need to remove assigned roles from a user prior to deleting the user.
:server user addand
:server user listcommands. In the example below, you can see a preview of available actions.
All individual user management actions are exposed through built-in System Procedures, meaning these actions can be scripted if needed.
View All Users and Roles
An admin can view the details of all defined users and roles. Neo4j 3.1 introduces four new System Procedures:
The example below lists four users and their respective roles. User
annehas no roles assigned and is required to change her password upon her next login. User
billis suspended and will not be able to log in until activated by admin.
dbms.security.listRoles(), we can see all defined roles in the system. The example below shows that role architect is not assigned to any user, and shows two publishers, John and Bob, and one reader, Bill.
You can easily view all roles assigned to a user:
Also, you can list all users that have a given role assigned:
Create and Delete Any Other User
The example below creates a new user called
abc. It includes the requirement to change the password at the user’s next (first) login.
Deleting a user named
janebrownis just as straightforward.
Assign and Remove Role from User
You can easily assign the role
And you can just as easily remove the role
Create and Delete Custom Roles
Admins can create and delete custom roles. Note that both roles are case sensitive, so
testRoleis not the same as
testrole. The example below creates role
operatorand then deletes the same role.
Suspending and Activating Users
Finally, let’s review System Procedures to suspend and activate users. The example below suspends user
janeand then activates the same user.
Managing User Passwords
Administrators can change the password of any user. The following example changes the password for
Native Users Can View Assigned Roles and Change Their Passwords
Any active user can view their own assigned roles. In this example, the logged-in user is
johnsmith, who is assigned reader and publisher roles with no extra flags set.
Active users can change their passwords. In this example, a user changes her password to
Synchronize Native Users across Cluster
Native users in Neo4j are stored securely on disk in each Neo4j instance. Neo4j automatically reloads the stored users and assigned roles from disk every five seconds. By default, the changes apply to the Neo4j instance where the commands were executed. The changes are not automatically propagated across a cluster of Neo4j instances.
If you need to make changes to native users and synchronize them across the cluster, you can:
- Manually copy relevant users and roles files on disk to all other cluster instances
- Use a network folder to store users and roles files
- Create an automated process that synchronizes the stored data across the cluster (e.g., here is an excellent rsync example)
As you can see, native user security and access control in Neo4j Enterprise Edition is designed to be both flexible and customizable to your database security needs without being overly complicated. These native user features ensure that only authenticated users and applications can access your graph database.
In the coming weeks, we’ll take a closer look at federated users via the LDAP connector, query management, security event logs, custom plugins, user-defined procedures and more. In the meantime, download the enterprise security white paper below to dive into more details.
Read the White Paper
Catch up with the rest of the Neo4j graph database security series:
About the Author
Igor Borojevic, Director of Product Management
Igor Borojevic is Director of Product Management at Neo Technology based in San Mateo, CA. At Neo Technology, Igor is focusing on development of enterprise features such as Security and Operability (in the cloud or on premise). He combines over 15 years of professional experience in consulting, professional services and product management. Before joining Neo, he worked at eBay as product owner for in-house machine translation service enabling cross-border commerce. Twitter: @iboroje
From the CEO
Have a Graph Question?
Reach out and connect with the Neo4j staff.Stackoverflow
Share your Graph Story?
Email us: email@example.com