Access control that can be applied to vertices, edges and vertex properties

[mikel...@gmail.com]

I have an idea for an attribute-based access control that can be applied to vertices, edges or vertex properties. The control would contain information about attributes, and the combinations of those attributes, that would be required for a user to retrieve or perhaps even traverse that graph element. A traversal strategy could then be constructed to only touch those elements that the user has privileges to access, and then any subsequent queries to the graph would have this constraint applied. I have so far been unable to construct a query or traversal strategy with Gremlin that can achieve the fine-grained access control that I think could be done.

I have worked on a prototype implementation, but I wanted to ask whether this is a feature that people could see being part of JanusGraph, or whether it is something that would be best left to Gremlin.

Thanks

[Florian Hockmann]

Fine grained access control that works on the basis of vertices and / or edges is definitely a nice feature in my opinion that is currently missing from all graph databases, at least as far as I know.

You could also ask on the TinkerPop developer mailing list whether this is something that could be added directly to TinkerPop, probably in Gremlin Server. Maybe you'll also get some general tips for the implementation.

Otherwise, it definitely makes sense to add this to JanusGraph in my opinion.

[Oleksandr Porunov]

The feature would be definitely very useful. As Florian said, it is better to ask TinkerPop developers if they could add it directly but nevertheless, I would like to see this feature in JanusGraph.

[Stephen Mallette]

I'd agree that it's a nice feature and I think that people would like to use something like that. The question I would have is in understanding whether or not something could be built generally that would actually scale well for all graphs. My general feeling is that role based access control is a feature that should be implemented by the underlying graph natively so as to take advantage of provider specific APIs and capabilities and generalizing such things might end up looking a lot like trying to generalize transactions or indexing which we've learned doesn't work well.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/9b8542c1-6fb2-4a2e-bd7e-d3cc524e170a%40googlegroups.com.

[Lakshay Rastogi]

Hi,

I've been a long time subscriber here and just read along. Very interesting and informative when I'm able to follow along.

Getting to why I jumped in, could you share how the architecture for this would look aka what your idea is?

To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/CAA-H43_Qp50pS_RJzofBd_Fx_00EqCX90pMW%3D4bRZav4VDCjaQ%40mail.gmail.com.

[mikel...@gmail.com]

Thank you very much for the replies. I haven't done it yet, but I intend to get in touch with the Tinkerpop developers and get some advice.

My prototype was pretty crude and simple. Along the same lines as the GeoShape data type, I added another one which is an AccessControl. The interface contains a single method that returns true or false depending on whether a supplied Principal (an object representing a user's privileges and constructed under some scheme) is allowed to access it. I then added a predicate which can perform this check as part of a traversal. On the surface, it just checks whether an AccessControl property is accessible by a Principal, but with Gremlin, you can roll it into a 'where' step so that vertices, edges, or vertex properties will be returned if accessible by the Principal. The follow-on, which was what I was most interested in, was putting this check in a Strategy so that a query would contain the filter implicitly.

I'm pretty amateur and so I haven't look into the overall performance considerations, or how this approach scales for larger numbers of vertices or more complex traversals. The main idea is that anyone that wants to use JanusGraph to support part of their application could easily supply a scheme for how privilege and access is constructed, which could be based on some other external source of truth.

On Friday, 27 December 2019 03:23:46 UTC+13, Lakshay Rastogi wrote:

Hi,

I've been a long time subscriber here and just read along. Very interesting and informative when I'm able to follow along.

Getting to why I jumped in, could you share how the architecture for this would look aka what your idea is?

On Tue, Dec 24, 2019, 5:01 PM Stephen Mallette <spmal...@gmail.com> wrote:

I'd agree that it's a nice feature and I think that people would like to use something like that. The question I would have is in understanding whether or not something could be built generally that would actually scale well for all graphs. My general feeling is that role based access control is a feature that should be implemented by the underlying graph natively so as to take advantage of provider specific APIs and capabilities and generalizing such things might end up looking a lot like trying to generalize transactions or indexing which we've learned doesn't work well.

On Mon, Dec 23, 2019 at 9:37 PM Oleksandr Porunov <alexand...@gmail.com> wrote:

The feature would be definitely very useful. As Florian said, it is better to ask TinkerPop developers if they could add it directly but nevertheless, I would like to see this feature in JanusGraph.

On Friday, December 20, 2019 at 3:19:57 PM UTC-8, mikel...@gmail.com wrote:

I have an idea for an attribute-based access control that can be applied to vertices, edges or vertex properties. The control would contain information about attributes, and the combinations of those attributes, that would be required for a user to retrieve or perhaps even traverse that graph element. A traversal strategy could then be constructed to only touch those elements that the user has privileges to access, and then any subsequent queries to the graph would have this constraint applied. I have so far been unable to construct a query or traversal strategy with Gremlin that can achieve the fine-grained access control that I think could be done.

I have worked on a prototype implementation, but I wanted to ask whether this is a feature that people could see being part of JanusGraph, or whether it is something that would be best left to Gremlin.

Thanks

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/9b8542c1-6fb2-4a2e-bd7e-d3cc524e170a%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@googlegroups.com.

[Stephen Mallette]

in case anyone was interested in the ongoing discussion happening with this on the TinkerPop dev list you can find the thread here:

https://lists.apache.org/thread.html/93dd56cc78237079fd51636dfa110d581edacc0daa0668bd282d4a65%40%3Cdev.tinkerpop.apache.org%3E  

To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/62665dfe-0f49-49be-bde6-30d3afeabf44%40googlegroups.com.