29 Mar 2016 by Michal Bachman
For most organisations, data security is extremely important. The topic comes up every single time we are training, consulting, or otherwise engaging in the world of graphs and Neo4j. At the same time, security is very difficult and time-consuming to get right and the implications of getting it wrong can be serious. In this blog post, we introduce the integration of Spring Security into Neo4j which provides important security controls and mechanisms for enterprises and governments that make use of the world’s most popular graph database.
Neo4j comes with certain security mechanisms out of the box. These include HTTPS support, single-user authentication with all-or-nothing authorization, and a handful of mechanisms to close off possible paths for malicious behaviour. Moreover, Neo4j will enhance its security controls portfolio in soon-to-be-released 3.0 version. However, many enterprises will be looking for features that go beyond the out-of-the-box offering. These include session and password expiration policies, password strength policies, flexible choices of where and how to store user details, different levels of authorization, and many more.
Spring Security is very a powerful, battle-tested, open-source framework for authentication and authorization in Java applications. It supports all commonly needed security features and can be easily configured and extended to provide custom functionality.
In order to meet our clients’ security requirements, we have built quite a unique, production-ready integration of Spring Security and Neo4j and developed a few additional components that make the integration natural and seamless.
The integration of Neo4j and Spring Security is shipped as a module of the GraphAware Framework and is called GraphAware Enterprise Security. It is compatible with Neo4j Enterprise Edition and forms the core of GraphAware’s Enterprise offering, which also includes auditing and advanced schema enforcement discussed in subsequent blog posts.
GraphAware Enterprise Security is essential for organisations that give multiple users or applications, internal or public, direct access to Neo4j. Organisations that use Neo4j as a database for a single application and enforce security in the application layer without exposing the database to any other clients will be just fine securing the database with its out-of-the-box features.
As in Spring Security, there are two main concerns in GraphAware Enterprise Security: authentication and authorization.
On the authentication front, GraphAware Enterprise Security ships with four different configurable authentication methods, each of which has its own merits and drawbacks. The main difference between them is where user details and credentials are stored. It goes without saying that passwords are never stored in plain text.
The first one is really straightforward. Integration with existing LDAP directories can be easily configured, leaving most of the authentication concerns to an external system. User roles coming from LDAP must be mapped to GraphAware Enterprise Security roles using a configuration file. We discuss these roles shortly in the Authorization section of this post.
The second (and also the default) option is storing user details, credentials, and roles in Neo4j in the form of graph properties. Graph properties are a special place in the graph that is not very well known. It behaves exactly like a node or a relationship in the sense that it can store properties, but doesn’t “pollute” the graph with additional nodes or relationships. Using this approach, credentials are automatically replicated across the Neo4j cluster, whilst keeping the graph clean.
When the database is completely wiped using Cypher, user information survives. However, the user information is still database-specific, so deleting the directory where Neo4j stores its data (which is quite a common way of deleting all data) or pointing Neo4j to a different data directory will require the re-creation of all user information.
In some cases, users of the graph actually need to be represented as nodes, so that they can be interlinked with the rest
of the data. For this reason, GraphAware Enterprise Security provides the option of storing user-related information on
With this strategy in place, user information is replicated across the cluster automatically, but does not survive any sort of database
In case it is required that user information survive the deletion of a database and using LDAP is not an option, GraphAware Enterprise Security provides a mechanism of storing user information in a file on disk, outside Neo4j’s data directory. This is, in fact, the same mechanism that Neo4j today uses to store the credentials of its single user. The disadvantage of this approach is that no automatic replication happens across the cluster and must be handled manually.
The following table summarises the authentication methods offered by GraphAware Enterprise Security:
|Method||Survives Deleted Database||Automatic Cluster Replication|
GraphAware Enterprise Security ships with six different roles (permissions):
These roles are enforced on the database Kernel level with Transaction Event Handlers, no matter what surface is exposed to the users. In case a user that is not allowed to delete, for example, executes a Cypher query that would delete nodes or relationships, the transaction will be failed and rolled back.
GraphAdmin, a simple user interface, ships with GraphAware Enterprise Security. For regular users, it allows login / logout and changing their password. USER ADMINs can administer users, their credentials and permissions from this interface. For ADMINs, other administrative functionality is exposed.
If you would like to give GraphAware Enterprise Security a try, get in touch and we will set up a demo for you. If you happen to attend GraphConnect, which we highly recommend, make sure to find GraphAware’s sponsor booth, where we can give you a demo in person. Use GRAPHAWARE30 as a discount code for 30% off of the conference ticket.
GraphAware Enterprise is a commercial open-source solution. This means the source is not available to general public but it is provided to our customers together with the software. A short GraphAware Neo4j Expert engagement is mandatory to ensure proper implementation of the solution to the enterprise. Please note that GraphAware Enterprise is not compatible with Neo4j Community Edition.
Customers who purchase a Neo4j licence through GraphAware automatically get access to GraphAware Enterprise, including 24/7 support for the software. If you already have a Neo4j subscription from Neo Technology or another Solution Partner and would like to use GraphAware Enterprise, please contact us.
We are looking forward to hearing from you!