[
https://issues.apache.org/jira/browse/TINKERPOP-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231997#comment-17231997
]
ASF GitHub Bot commented on TINKERPOP-2389:
-------------------------------------------
vtslab edited a comment on pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#issuecomment-726770564
Another consideration is the authorization of OLAP requests (initially also
mentioned by @FlorianHockmann). For HadoopGraph it seems sufficient to give
some users access and others not. Here, one could use a new
ComputerDenyStrategy.
For TinkerGraphComputer and FulgoraGraphComputer that run inside the Gremlin
Server instance, OLAP also might be legitimate for some users, but here you
would like to restrict the number of workers that a client can request, e.g. to
4 to give some speed up with respect to OLTP, but not drain the server. Here,
one would rather have some WorkerRestrictStrategy. Of course, the two could
coincide if you allow for WorkerRestrictStrategy.build.set(0).create(). Any
opinions?
[Edited] we also have the scripEvaluationTimeout, but this does not seem to
protect against requesting a large number of computer workers.
[2nd edit] There is also the VertexProgramStrategy that is inserted into the
bytecode by the withComputer() step automatically. This can be inspected by an
Authorizer if it wants to deny OLAP. So, my comments above are only relevant
for consistency: one can configure a GraphTraversalSource with a
ReadOnlyStrategy, but there is no ComputerDenyStrategy. But forget about the
WorkerRestrictStrategy because restricting computer workers is better handled
by the Authorizer.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Authorization support in TinkerPop
> ----------------------------------
>
> Key: TINKERPOP-2389
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2389
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.4.7
> Reporter: Shekhar Bansal
> Priority: Major
> Attachments: Screenshot 2020-06-25 at 15.15.04.png
>
>
> Use case:
> # Tinkerpop supports multiple graphs using a single API and admin might want
> to restrict access to some of the graphs.
> # Admin might want to restrict read/write access to certain users.
>
> Proposal
> Add read/write access restrictions at graph level. We can extend it to
> executing scripts by adding execute privileges.
>
> Changes required
> Add `authorizer` block similar to `authentication` block in yaml file
>
> {code:java}
> authorization: {
> authorizer:
> org.apache.tinkerpop.gremlin.server.authorization.AllowAllAuthorizer,
> authorizationHandler:
> org.apache.tinkerpop.gremlin.server.handler.SaslAuthorizationHandler,
> config: {
> }
> }{code}
>
> Authorization will be done only if authentication is enabled. Authentication
> is done at per session basis while authorization will be done for each and
> every request.
> In `SaslAuthorizationHandler` or `HttpAuthorizationHandler` query will be
> parsed and depending on the step instructions, the query will be marked as of
> type read or write and then privilege evaluation will be done by calling
> `isAccessAllowed` method of `Authorizer`
> {code:java}
> public interface Authorizer {
> /**
> * Whether or not the authorization requires check.
> * If false will not authorzie user.
> */
> public boolean requireAuthorization();
> /**
> * Setup is called once upon system startup to initialize the {@code
> Authorizer}.
> */
> public void setup(final Map<String, Object> config);
> /**
> * A "standard" authorization implementation
> */
> public boolean isAccessAllowed(AuthorizationRequest authorizationRequest)
> throws AuthorizationException;
> }
> {code}
> Access policies can be defined in tools like `Apache Ranger`, sample policy:
> !Screenshot 2020-06-25 at 15.15.04.png|width=1017,height=548!
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
