[
https://issues.apache.org/jira/browse/TINKERPOP-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216847#comment-17216847
]
ASF GitHub Bot commented on TINKERPOP-2389:
-------------------------------------------
QwentB commented on pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#issuecomment-712263821
Thanks for your answer @vtslab
I agree that caching authorization have a memory impact and that it does not
make sense with a "many users submitting few requests" scenario, on the other
hand, if you consider the gremlin server as a storage backend accessed by a few
front-end servers (so a "few users / many requests" scenario) caching the
authorizations makes more sense. You're absolutely right that it should
definitely have some configurable limits and eviction strategy.
All this being said, caching was just an example of the possibilities
offered to potential implementations, my main point was more "separation of
concerns" related as, IMO, the authorization provisioning should be separated
from the authorization process itself.
Regarding the second point, I might be misunderstanding what you mean by:
> "Add/remove Strategies can be done by offering the same graph via
different GraphTraversalSources that differ by the Strategies applied"
, but I guess you're referring to the statically defined traversalSources in
the server's configuration file. The use case being the definition of a
`graph1ReadOnly` traversal sources pointing to `graph1` but with a
ReadOnlyStrategy, and then make sure `ReadOnlyUser` can only access
`graph1ReadOnly`, and the same principle could be applied to a
`graph1WithoutConfidentialData` traversal source with a SubgraphStrategy
applied.
I agree that request message analysis coupled with such configuration
provides some interesting features and will cover some use cases, but it is not
applicable to an ABAC implementation where the potential combinatory of all
attributes does not allow the static definition of all possible traversal
sources. With the Authorizer interface returning a RequestMessage, an
Authorizer could, for example, inject a SubgraphStrategy matching the exact
authorizations of the user and effectively limitating the visbility.
I'm also wondering why the Authorizer is currently returning an
AuthorizedUser which does not contain much and does not seems to be used
anywhere afterward. If the idea is to add it to the context and use it later
down the pipeline, for example, to call the "withAuthorizaton' method of an
AuthorizedTraversalSource, I thing we're back to point #1 about storing data in
the context.
----------------------------------------------------------------
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)
