Good to read that you see opportunities to support some authorization functionality in TinkerPop. Thanks for your feedback.
@Stephen, it is indeed the plugin interface that I am most unsure about, but your confirmation of the underlying ideas and Florian's listing of elements of the interface certainly help me in making my prototype more concrete. An example implementation can be part of the examples module and need not be production code. @Florian, maybe it was not entirely clear from my description, but once you allow an authorization plugin to police based on the name of the selected GraphTraversalSource (among other elements of the user request), it is entirely up to the user's admin how he/she defines the GraphTraversalSource in Gremlin Server in terms of applied strategies and the underlying datamodel (in other words, the plugin interface would not advocate or limit the use of the SubgraphStrategy or imply any data model). But this is probably easier discussed, when the proposed plugin interface is available. Your description of stages would certainly be necessary when you would provide an entirely other type of interface in terms of grant/revoke statements (as offered in some commercially licensed TinkerPop implementations). I did not consider such an interface (or extension of the GraphManagerer API) in the current proposal, though, because it would be a significant leap in terms of TinkerPop modules affected. On 2020/06/15 12:45:58, "Florian Hockmann" <[email protected]> wrote: > Thanks for starting this discussion and for the proposal, Marc! I think > authorization is something that many users want and that TinkerPop should > offer in the long term. > > I think it would good to make it easy to limit things as the following to > specific users / groups (most of which you already mentioned in your blog > post): > Writeable access > OLAP traversals > Lambdas > Executing scripts > > An interface that makes it easy to allow or deny a traversal / query based on > these properties with a simple example implementation sounds like a good > solution to me. > > This could later maybe be extended to limit access to certain parts of the > graph (e.g, based on vertex/edge labels or values of a special meta property) > but that is probably too complicated for a first version so I would consider > it out of scope for now. > > -----Ursprüngliche Nachricht----- > Von: Stephen Mallette <[email protected]> > Gesendet: Montag, 15. Juni 2020 13:59 > An: [email protected] > Betreff: Re: [DISCUSS] Proposing authorization for Gremlin Server > > I think authorization would be a helpful addition for some users so in that > sense I'm in favor of such a feature. I"m mostly concerned with the "how" > part and the interfaces we expose to make it happen. I think I'd be in favor > of a solution that was > > * interface/plugin based > * not terribly prescriptive in terms of functionality > * lacking a production-ready reference implementation > > Basically, it would be great if we took what we might currently prescribe as > a best practice for authorization and turned it into something easily > implemented by a provider or user. It should be less hard to implement than > writing a custom Channelizer with custom Netty handlers but be more effort > than just tinkering with configuration files. > > I realize that's all very high-level, but I just wanted to express my > thoughts on what I think Gremlin Server should offer in this area as > "authorization" has a really wide surface area as a feature. > > > > On Thu, Jun 11, 2020 at 4:14 PM Marc de Lignie <[email protected]> > wrote: > > > For a specific use case in my employer's organization I did some > > initial work on opening up Gremlin Server to authorization plugins. It > > would certainly be stimulating to enable a wider audience to use this > > work by contributing it to Apache TinkerPop. But I realize that, given > > the complexity of authorization and its dependence on other TinkerPop > > features, it is certainly not obvious that the TinkerPop team would > > want to support it. The more so because of indications that the > > TinkerPop team wants to move to a more focussed re-implementation > > based on recent theoretical and managerial insights (TP4). > > > > To facilitate a discussion whether or not to support authorization for > > Gremlin Server in some way, I have written a concrete proposal > > published at > > > > https://yaaics.blogspot.com/2020/06/proposing-authorization-for-gremli > > n.html > > > > I hope you can give it some attention and formulate your arguments in > > favor or against it on the dev mailing list, or maybe provide > > perspectives on an alternative proposal. > > > > Best wishes, Marc > > > > > > > > > >
