Yes - you could do a TraversalStrategy in the manner you described. It would be relatively easy especially with a really simple access control model. The question I'm raising is whether or not that approach to an implementation is going to really solve access control problems in a way that users will find fitting for production use cases or are we just building "yet another thing". If we're just using a TraversalStrategy to do username checks on property values by injecting has() filters everywhere I'd wonder what the performance cost of such an implementation would be. If indices help, it is now incumbent upon the user to know how to properly create those index structures across their entire graph and these values must all be encoded into the schema itself. If indices don't help then now we're in-memory filtering every single access to every single piece of data there is. Either way, I think these barriers create usage issues that users won't grapple with well.
i think that this goes back to the point Pieter made earlier in the thread about schema for TP4 where TinkerPop sits far from the data[1]. I'm basically echoing that concern for this particular use case. I think that ideally, a graph should implement its own form of ACL based on it's own architecture. TinkerPop simply provides the "username" as part of the RemoteConnection and the graph uses that username to apply the ACL to all the traversals executed with that user. In this way, Gremlin only ever processes the data that it has access to and the data it doesn't its filtered at its source. I'm concerned that if we generalize ACL into TinkerPop in the way that's presented here we could end up with an implementation that only works with TinkerGraph and small in-memory graphs. Every time we put something out there like that it just ends up reflecting badly back at us. [1] https://lists.apache.org/thread.html/c57d5f17306e127be74d6d106ae32152a6250d5397f6d78b67c9abfb%40%3Cdev.tinkerpop.apache.org%3E On Mon, Jan 6, 2020 at 8:13 AM Florian Hockmann <[email protected]> wrote: > > 4. As I think about how users initialize a TraversalSource, I can't help > thinking that implementing this feature as a TraversalStrategy places it at > the wrong level of abstraction. > > Currently, authentication is done on the connection level, but that gets > much more difficult if it should be done on a per-element (vertex, edge, > maybe even vertex property) basis. It should be relatively straightforward > to implement this as a TraversalStrategy as it would only need to insert > has(userId, currentUserId) steps for all traversed elements (+ equivalent > property steps for all modifications). Do you have a different approach in > mind that can work on a higher level of abstraction? > If it's implemented as a TraversalStrategy, then it needs to be ensured > that the strategy is applied to all traversals and that the correct userId > is used (so the one that the user has provided valid credentials for). > > -----Ursprüngliche Nachricht----- > Von: Stephen Mallette <[email protected]> > Gesendet: Freitag, 3. Januar 2020 12:44 > An: [email protected] > Betreff: Re: Access controls for vertices, edges and vertex properties > > Thanks for posting your idea. As others on the list may not have seen my > post elsewhere, I'll just quickly repeat an approximation of what I wrote. > Basically, I think that users would like a feature like this, but I > wondered if it were something best left to graph providers to implement > native to their systems as an unoptimized implementation may not perform > well or behave with limited functionality. So, with that in mind, here's > some further thoughts/questions: > > 1. Could you say some more about how the "access control property" is > defined? How would you envision such a thing to be generalized across all > graphs providers? > 2. Could you share some sample code for how you define your "custom > predicate" and what the TraversalStrategy does with that (basically, please > show how all that wraps up with Gremlin)? > 3. Please keep in mind that any solution here must be portable across all > programming languages - will users be able to define the required objects > in python, javascript, etc? > 4. As I think about how users initialize a TraversalSource, I can't help > thinking that implementing this feature as a TraversalStrategy places it at > the wrong level of abstraction. The notion of a "user" who has access > rights is bound to the RemoteConnection (Cluster/Client). It is through > that method that the graph is aware of who the user is and from that > initial authenticating handshake can govern the data that the user sees. > While that thinking applies to remote graphs, it might also apply to > embedded graphs as well where the "user" is supplied by way of the > Configuration object given to the Graph instance where subsequent > TraversalSource constructs would inherit from that. > > > > > > On Thu, Jan 2, 2020 at 6:55 AM Mike Lee <[email protected]> wrote: > > > Hello > > > > Apologies if this is the incorrect forum - I was pointed here from > > another mailing list. > > > > I had an idea for an access control scheme that could be applied to > > vertices, edges or vertex properties and would allow a server to check > > whether a user has permission to retrieve or traverse that particular > > graph element. The access control property would be a set of rules > > outlining the attributes, and the combination of those attributes, > > that establish whether or not a user has sufficient privileges for > > that graph element. I have experimented with attempting to use the > > existing Gremlin language to do this, but I have so far been unable to > > achieve the level of fine-grained access control that I believe would > > be useful in a variety of situations. I have tested this with a > > prototype that uses a Java object and a custom predicate that tests a > > user's profile against the access control, and then used a traversal > > strategy to constrain a query to those elements which pass the test. > > > > I was curious as to whether people would see such a feature as > > something that could be part of Gremlin, or whether it would be better > > left to specific implementations of Tinkerpop. > > > > Thanks for your consideration. > > > >
