[
https://issues.apache.org/jira/browse/TINKERPOP-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189974#comment-17189974
]
ASF GitHub Bot commented on TINKERPOP-2389:
-------------------------------------------
QwentB commented on pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#issuecomment-686356336
@vtslab Thanks for your answer.
Yes the client receive a token after authenticating on an identity provider
service, which might be part of the same infrastructure (i.e. a corporate
service) or external (Google, Facebook ...). However, when the token is
received by the consuming service (Janus or Gremlin here), it should be
validated (signature, issuer, date time of issue, end of validity...) before
being accepted as valid credentials. Considering the actual authentication
scheme in Gremlin, this is a typical SASL use case and the token validation
process is the "real" local authentication handled by the Authenticator.
It means that the Authenticator will have to "open" the token to extract the
subject (aka the user id) but might as well extract all other claims (aka user
attributes/properties) available in the token. My point is that if these
attributes were to be used in the authorization process, the Authorizer must be
provided with either the attributes (extracted by the Authenticator), or the
token (and then reopen it and extract all attributes). IMO it make sense to
deal with the token only once, for obvious performance reasons, but also for an
ABAC Authorizer to be independent of the Authentication mechanism. With this in
mind, the AuthenticatedUser seems to be the right container to convey these
data.
The JWT authentication shall be used for both HTTP requests and WebSockets.
For WebSockets, the authentication happens during the initial connection and
before the request upgrade, so if the AuthenticatedUser with the attributes is
available in the ChannelContext, it can used by the authorization process each
time a RequestMessage is received.
----------------------------------------------------------------
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:
us...@infra.apache.org
> 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)
