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 Thu, 03 Sep 2020 09:03:08 GMT

QwentB commented on pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#issuecomment-686356336

   @vtslab Thanks for your answer.
   Yes the client receive a token after authenticating on an identity provider service, which
might be part of the same infrastructure (i.e. a corporate service) or external (Google, Facebook
...). However, when the token is received by the consuming service (Janus or Gremlin here),
it should be validated (signature, issuer, date time of issue, end of validity...) before
being accepted as valid credentials. Considering the actual authentication scheme in Gremlin,
this is a typical SASL use case and the token validation process is the "real" local authentication
handled by the Authenticator.
   It means that the Authenticator will have to "open" the token to extract the subject (aka
the user id) but might as well extract all other claims (aka user attributes/properties) available
in the token. My point is that if these attributes were to be used in the authorization process,
the Authorizer must be provided with either the attributes (extracted by the Authenticator),
or the token (and then reopen it and extract all attributes). IMO it make sense to deal with
the token only once, for obvious performance reasons, but also for an ABAC Authorizer to be
independent of the Authentication mechanism. With this in mind, the AuthenticatedUser seems
to be the right container to convey these data.
   The JWT authentication shall be used for both HTTP requests and WebSockets. For WebSockets,
the authentication happens during the initial connection and before the request upgrade, so
if the AuthenticatedUser with the attributes is available in the ChannelContext, it can used
by the authorization process each time a RequestMessage is received.

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:

View raw message