Details

      Description

      Provide some method to allow for authentication to Gremlin Server.

        Activity

        Hide
        drobin1437 David Robinson added a comment -

        Hey, Curious about your thoughts when you get around to this after GA.

        Ideally, authentication could be configured uniquely for each graph supported by the gremlin server with a technique that also supports dynamic addition of graphs to the server.

        Maybe basic auth for each graph as an entry level flow.
        Also cool would be an open id connect flow.

        Show
        drobin1437 David Robinson added a comment - Hey, Curious about your thoughts when you get around to this after GA. Ideally, authentication could be configured uniquely for each graph supported by the gremlin server with a technique that also supports dynamic addition of graphs to the server. Maybe basic auth for each graph as an entry level flow. Also cool would be an open id connect flow.
        Hide
        spmallette stephen mallette added a comment -

        Just some quick thoughts on this as I've not had more than quick thoughts on this issue. This issue was about authentication for requests to gremlin server and not authorization as to what graphs one might have access to, but perhaps authorization is tied into this in some way. I hadn't thought that far ahead.

        Users currently have methods open to them to implement their own authentication/authorization schemes. You just have to implement your own Channelizer implementation to inject your custom security handler and configure it in the yaml file. To some degree, I wonder if adding specific "authentication" and "authorization" extension points to Gremlin Server infrastructure can make that process any easier. For authentication, I suppose there could be some out-of-the-box security handlers for openid, ldap, whatever, and they could be configured via some secure implementation of a Channelizer or maybe even the existing ones somehow with new configuration capabilities there.

        I don't think the protocol would have to change. I think we can just pass username/password as keys in the RequestMessage arguments...simple enough.

        Going back to authorization, that's a bit more tricky because all graphs get bound to the ScriptEngine for every request. I suppose there would be room to have an authorization mechanism be consulted to determine which Graph and/or TraversalSource bindings were supplied given an authenticated user.

        Show
        spmallette stephen mallette added a comment - Just some quick thoughts on this as I've not had more than quick thoughts on this issue. This issue was about authentication for requests to gremlin server and not authorization as to what graphs one might have access to, but perhaps authorization is tied into this in some way. I hadn't thought that far ahead. Users currently have methods open to them to implement their own authentication/authorization schemes. You just have to implement your own Channelizer implementation to inject your custom security handler and configure it in the yaml file. To some degree, I wonder if adding specific "authentication" and "authorization" extension points to Gremlin Server infrastructure can make that process any easier. For authentication, I suppose there could be some out-of-the-box security handlers for openid, ldap, whatever, and they could be configured via some secure implementation of a Channelizer or maybe even the existing ones somehow with new configuration capabilities there. I don't think the protocol would have to change. I think we can just pass username/password as keys in the RequestMessage arguments...simple enough. Going back to authorization, that's a bit more tricky because all graphs get bound to the ScriptEngine for every request. I suppose there would be room to have an authorization mechanism be consulted to determine which Graph and/or TraversalSource bindings were supplied given an authenticated user.
        Hide
        spmallette stephen mallette added a comment -

        Implementing SASL-based authentication for driver and server. This will allow plugin of different authentication schemes. Expect to include a simple "plain text" implementation out-of-the-box.

        Show
        spmallette stephen mallette added a comment - Implementing SASL-based authentication for driver and server. This will allow plugin of different authentication schemes. Expect to include a simple "plain text" implementation out-of-the-box.
        Show
        spmallette stephen mallette added a comment - see - https://groups.google.com/d/msg/gremlin-users/UoCAoR2-WWY/0Q_MTcfPGGoJ

          People

          • Assignee:
            spmallette stephen mallette
            Reporter:
            spmallette stephen mallette
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development