[
https://issues.apache.org/jira/browse/TINKERPOP-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199321#comment-17199321
]
ASF GitHub Bot commented on TINKERPOP-2389:
-------------------------------------------
QwentB commented on pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#issuecomment-696037519
Thanks @spmallette for linking to two threads as they're obviously related.
I'm not sure if it would cover all possible use cases, but the Authorizer
could return the RequestMessage instead of the AuthorizedUser. It would allow
an implementation to do some pre-checks (script vs bytecode, VertexProgram,
Lambda, use of specific strategies or steps...), but also update the
RequestMessage by adding/modifying steps, add/remove Strategies or even change
the "resource" that will be effectivelly bound to the request.
As pointed by @vtslab, the user's authorizations must be available in the
context for WebSocket requests, so they can be applied without requiring
authentication. If the Authorizer return a RequestMessage, an
AuthorizedUserProvider component is probably needed to build the actual
AuthorizedUser and add it to the channel context.
The pipeline would then look like:
1. `Authenticator` returns the `AuthenticatedUser`
2. `AuthorizedUserProvider` takes the `AuthenticatedUser` as parameter and
return the `AuthorizedUser` which will be added to `ChannelContext`
3. `Authorizer` takes the `AuthorizedUser` and the `RequestMessage` as
parameters and return a potentialy updated `RequestMessage`
This require the AuthorizedUser to contains the authorizations for the user.
To stay agnostic of any implementation, the AuthorizedUser could be specified
as a parametrized class defining the authorizations' type. It might also be
relevant that the AuthorizedUser contains some global metadata about the
authorizations (i.e. date time of issue to force a renewal).
In the end the AuthorizedUser could look like:
```
**
* @param <A> the type of Authorizations
*/
public class AuthorizedUser<A> {
private final String name;
private final Map<String, Object> metadata;
private final Map<String, A> authorizations;
/**
* Construct an AuthorizedUser instance
*
* @param name the name of the AuthenticatedUser
* @param metadata a key/value store for information about the
given authorizations
* @param authorizations the authorizations given to the user for each
resource
*/
public AuthorizedUser(String name, Map<String, Object> metadata,
Map<String, A> authorizations) {
this.name = name;
this.metadata = metadata;
this.authorizations = authorizations;
}
public String getName() {
return name;
}
public Map<String, Object> getMetadata() {
return metadata;
}
public Map<String, A> getAuthorizations() {
return authorizations;
}
}
```
----------------------------------------------------------------
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)
