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