[
https://issues.apache.org/jira/browse/TINKERPOP-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249646#comment-17249646
]
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_r543280290
##########
File path: docs/src/dev/provider/index.asciidoc
##########
@@ -1147,25 +1147,43 @@ one key value pair present (since only one `Traversal`
is being submitted, there
single alias).
|=========================================================
-=== Authentication
+=== Authentication and Authorization
Gremlin Server supports
link:https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer[SASL-based]
authentication. A SASL implementation provides a series of challenges and
responses that a driver must comply with
-in order to authenticate. By default, Gremlin Server only supports the
"PLAIN" SASL mechanism, which is a cleartext
-password system. When authentication is enabled, an incoming request is
intercepted before it is evaluated by the
-`ScriptEngine`. The request is saved on the server and a `AUTHENTICATE`
challenge response (status code `407`) is
-returned to the client.
-
-The client will detect the `AUTHENTICATE` and respond with an `authentication`
for the `op` and an `arg` named `sasl`
-that contains the password. The password should be either, an encoded
sequence of UTF-8 bytes, delimited by 0
-(US-ASCII NUL), where the form is : `<NUL>username<NUL>password`, or a Base64
encoded string of the former (which
-in this instance would be `AHVzZXJuYW1lAHBhc3N3b3Jk`). Should Gremlin Server
be able to authenticate with the
-provided credentials, the server will return the results of the original
request as it normally does without
-authentication. If it cannot authenticate given the challenge response from
the client, it will return `UNAUTHORIZED`
-(status code `401`).
+in order to authenticate. Gremlin Server supports the "PLAIN" SASL mechanism,
which is a cleartext
+password system, for all
link:https://tinkerpop.apache.org/docs/current/tutorials/gremlin-language-variants/[Gremlin
Language Variants].
+Other SASL mechanisms supported for selected clients are listed in the
+link:https://tinkerpop.apache.org/docs/current/reference/#security[security
section of the Gremlin Server reference documentation].
+
+When authentication is enabled, an incoming request is intercepted before it
is evaluated by the `ScriptEngine`. The
+request is saved on the server and a `AUTHENTICATE` challenge response (status
code `407`) is returned to the client.
+
+The client will detect the `AUTHENTICATE` and respond with an `authentication`
for the `op` and an `arg` named `sasl`.
+In case of the "PLAIN" SASL mechanism the `arg` contains the password. The
password should be either, an encoded
+sequence of UTF-8 bytes, delimited by 0 (US-ASCII NUL), where the form is :
`<NUL>username<NUL>password`, or a Base64
+encoded string of the former (which in this instance would be
`AHVzZXJuYW1lAHBhc3N3b3Jk`). Should Gremlin Server be
+able to authenticate with the provided credentials, the server will return the
results of the original request as it
+normally does without authentication. If it cannot authenticate given the
challenge response from the client, it will
+return `UNAUTHORIZED` (status code `401`).
NOTE: Gremlin Server does not support the "authorization identity" as
described in link:https://tools.ietf.org/html/rfc4616[RFC4616].
+In addition to authenticating users at the start of a connection, Gremlin
Server allows providers to authorize users on
+a per request basis. If
+link:https://tinkerpop.apache.org/docs/x.y.z/reference/#_configuring_2[a java
class is configured] that implements the
+link:https://tinkerpop.apache.org/javadocs/x.y.z/full/org/apache/tinkerpop/gremlin/server/authz/Authorizer.html[Authorizer
interface],
+Gremlin Server passes each request to this `Authorizer`. The `Authorizer` can
deny authorization for the request by
+throwing an exception and Gremlin Server returns `UNAUTHORIZED` (status code
`401`) to the client. The `Authorizer`
+authorizes the request by returning the original request or the request with
some additional constraints. Gremlin Server
+proceeds with the returned request and on its turn returns the result of the
request to the client. More details on
+implementing authorization can be found in the
+link:https://tinkerpop.apache.org/docs/current/reference/#security[reference
documentation for Gremlin Server security].
Review comment:
Please use the template variable for the documentation version in your
link, thus: `https://tinkerpop.apache.org/docs/x.y.z/reference/#security`
----------------------------------------------------------------
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)
