[ 
https://issues.apache.org/jira/browse/TINKERPOP-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17221349#comment-17221349
 ] 

ASF GitHub Bot commented on TINKERPOP-2389:
-------------------------------------------

spmallette commented on a change in pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#discussion_r512633282



##########
File path: docs/src/reference/gremlin-applications.asciidoc
##########
@@ -942,8 +942,10 @@ The following table describes the various YAML 
configuration options that Gremli
 |authentication.authenticator |The fully qualified classname of an 
`Authenticator` implementation to use.  If this setting is not present, then 
authentication is effectively disabled. |`AllowAllAuthenticator`
 |authentication.authenticationHandler | The fully qualified classname of an 
`AbstractAuthenticationHandler` implementation to use. If this setting is not 
present, but the `authentication.authenticator` is, it will use that 
authenticator with the default `AbstractAuthenticationHandler` implementation 
for the specified `Channelizer` |_none_
 |authentication.config |A `Map` of configuration settings to be passes to the 
`Authenticator` when it is constructed.  The settings available are dependent 
on the implementation. |_none_
-|authentication.enableAuditLog |The available authenticators can issue audit 
logging messages, binding the authenticated user to his remote socket address 
and binding requests with a gremlin query to the remote socket address. For 
privacy reasons, the default value of this setting is false. The audit logging 
messages are logged at the INFO level via the 
`audit.org.apache.tinkerpop.gremlin.server` logger, which can be configured 
using the log4j.properties file. |false
+|authentication.authorizer |The fully qualified classname of an `Authorizer` 
implementation to use.  Gremlin server does not offer `Authorizer` 
implementations, but 
link:https://tinkerpop.apache.org/docs/x.y.z/dev/provider/#_authentication_and_authorization[graph
 system providers can choose to do so]. |_none_

Review comment:
       > graph system providers can choose to do so
   
   is it just up to graph system providers? couldn't users write them as well? 




----------------------------------------------------------------
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)

Reply via email to