This issue was created in the last few hours: https://issues.apache.org/jira/browse/TINKERPOP-2389
On Mon, Jun 15, 2020 at 3:04 PM [email protected] <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > >
