Native User Security & Access Control in Neo4j Enterprise [Security Series, Part 2]

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.

Native Users

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)

When admin suspends or deletes another user, the following rules apply:

• 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.

To simplify user management, the Neo4j Browser widget can be invoked with :server user add and :server user list commands. 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: listUsers, listRoles, listRolesForUser and listUsersForRole.

The example below lists four users and their respective roles. User anne has no roles assigned and is required to change her password upon her next login. User bill is suspended and will not be able to log in until activated by admin.



By invoking 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 johnsmith with password abc. It includes the requirement to change the password at the user’s next (first) login.



Deleting a user named janebrown is just as straightforward.

Assign and Remove Role from User

You can easily assign the role publisher to user johnsmith.



And you can just as easily remove the role publisher from user johnsmith.

Create and Delete Custom Roles

Admins can create and delete custom roles. Note that both roles are case sensitive, so testRole is not the same as testrole. The example below creates role operator and 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 jane and then activates the same user.

Managing User Passwords

Administrators can change the password of any user. The following example changes the password for joebloggs to h6u4%kr.

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 abc.

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)

Conclusion

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.




Catch up with the rest of the Neo4j graph database security series:

• Role-Based Access Control in Neo4j Enterprise Edition