tinkerpop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [tinkerpop] QwentB commented on pull request #1308: TINKERPOP-2389 WIP: Authorization support in TinkerPop
Date Mon, 21 Sep 2020 10:45:34 GMT

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:
users@infra.apache.org



Mime
View raw message