Multi-tenant solution for Dgraph

Users
1

Hi All,

As a followup to Possible timeline of implementing ACL's in Dgraph, and a continutation to some parts of the discussion at Indexes and Transactions - #7 by janardhan, I’m creating this thread as an attempt to start a discussion on how Dgraph can be used to support a multi-tenant application.

I will preface this by saying that I am not a SaaS expert, and my security experience is with single-tenant enterprise applications. However, here is a rough outline of the way security of our app should work, and hopefully we can go from a discussion of these high-level requirements to a specific solution for Dgraph.

Multi-Tenant Security Requirements

  1. “Namespace-driven” behavior. Namespaces include:
    a. Individual user namespace: private to user, with ability to share items with other specific users
    b. Group namespaces, including namespace hierarchies. Examples are “workspaces” and “projects” in Asana. Driven by security groups, controlled by the admin for the given namespace.
  2. Individual-user authentication with Dgraph database, and to have access to data controlled by individual- and group- level security natively at the database level. Criticality of tenant privacy requires a native database solution to ensure that access to information is predicated on secure authentication and explicit access to the information being requested.

Very interested in feedback on these requirements. Something I found interesting from Expero Blog | Multi-Tenant Applications in Neo4j is that even though Neo4j has been around for 10 years, per the article as of December 2016, Neo4j does not have a “comprehensive plan for multi-tenancy”. From my perspective, this is a critical and obvious capability to have in a graph database. Similar to the Dgraph team’s decision to tackle distributed transactions, maybe an early native multi-tenancy solution could provide yet another reason to choose Dgraph over competitors for SaaS applications.

1 Like
2

I have been thinking more about this. I wanted to create a post in the reverse direction - how would we create a secure access system with current Dgraph features (no database-level multi-tenancy features).

A first set of thoughts:

  1. Each entity would have a predicate called “Namespace”, and another called “Namespace key”. Namespace key could be generated by some hash function based on the user’s ID, and possibly a secret key stored in the database.
  2. Every query in the system which accesses user private data would have “func: eq(NamespaceKey, “key value”)” at the root, thus filtering results to the user’s namespace
  3. Group-level namespaces would have some similar scheme
  4. A user could share content in their private namespace, entity by entity, by having another key generated, maybe “GrantedAccessKey”. When content is shared, that “GrantedAccessKey” is associated with the user with whom the content has been shared. So when that target user runs a query, the root then looks like “func: eq(GrantedAccessKey, “key value”)”

This is just a rough idea. Maybe this approach would be necessary depending on the multi-tenancy feature set that makes sense from the Dgraph team’s product management perspective.

1 Like
3

Whatever the solution for multi-tenant support will be, I really hope that it will be implemented in an orthogonal way. In other words, only if you use it, you should have to pay for it in terms of performance and resource consumption.

1 Like
4

Thanks for the thoughts, @tamethecomplex. Busy with releasing v1.0 right now, but we’ll get back to this in the new year when we’re planning enterprise features.

2 Likes
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.