Hi Matt, All, This sounds great!
In addition to action based security, we'll probably have requests for functionality based security as well, e.g. a user is allowed to read from but not write to a database, so Table Input would be allowed, but Table Output, Insert/Update etc would be unavailable or disabled. A lot of these restrictions could fit into the policies we discussed earlier. Similar to messages on a locked object, having the option to suggest changes to a pipeline, action, transform etc, with the option to approve or reject, each with their own comments, would make reviews a lot more user friendly. Regards, Bart On Mon, Feb 15, 2021 at 11:33 AM Matt Casters <[email protected]> wrote: > Hello Hops, > > Now that Hiromu has been making absolutely stunning progress on merging his > Hop Web changes into the main code-line we're seeing > hiromuhota/hopweb:nightly behave like a champ. > > As a reminder you can give it a shot with: > > docker run -d -p 8080:8080 hiromuhota/hopweb:nightly > > That being said, a hop.war file is being generated in the main build now in > assemblies/web/target/hop.war You should be able to throw that into a web > server webapps folder to get it up-and-running. > > This does bring the security question around hop-web on the table though. > The requirements around this for me are essentially that we should be able > to develop data orchestration solutions in a browser with one or more > developers on the same server. This means allowing files to be changed by > multiple users, multiple git repositories and so on. I predict that things > can get problematic if we don't do something about that. > > *Security & ACLs* > > I think at some point we might want to implement some kind of mapping > between an authenticated user (say [email protected] authenticated via > OAuth) and a hop-web user. > > Now this hop-web user typically has access to all files on a server unless > we invent something to restrict that access. We could make it so that the > file dialog only allows you to browse to certain folders or more > specifically, specific project folders. > So the list of mappings could be: AuthenticationUser - HopUser - Project > > *Action based security* > > I can also see a use-case, obviously not just for hop-web, for having > action-based security with the absolute minimum being some sort of > read-only mode. > Action based security can be sprinkled throughout the GUI and runtime code > as long as we have the metadata to validate actions. > We need: > - User/Role ACL > - The subject (specific file, category, metadata object, ...) > - The action > - Allowed/Denied > - Arguments > > Example: User(matt) is Allowed to Action(execute) a Subject(pipeline) with > Argument(pipeline run configuration="local") > > Once we have this security metadata "database" somewhere we can just add > one-liner checks in the code. For example right before we run a pipeline: > > HopSecurity.validateAction( pipelineMeta, HopActionType.EXECUTE, ...); > > This could pick up the current user and validate it. If there is no > security layer defined or no user it will just be ignored. > > *Locking, messages & code review* > > Finally if you're working with multiple developers on the same project > there is a high chance that you'll be tempted to work on the same file at > some point. Having the ability to do a soft or hard lock on a pipeline or > workflow would be really nice to have (and fairly easy to implement). > If you open a file to work on you could see a message from a user > saying: "*Sorry, > I'm working on this file*". You'll open a read-only version of the file. > With a soft lock you should be able to just ignore this and edit anyway. > Messages also could be very easy to implement in the form of developer > notes on a file or project level (where it matters really). > Code-reviews finally are IMO just a variant of that with perhaps an extra > status that we keep on a file/project level. (Has remarks, partially > approved, approved) > If messages, locks and reviews are implemented as metadata objects we could > check them into the project itself. They'll become an intricate part of > the project itself. We could prevent a push to upstream in git for example > until the project review status has reached Approved status. > > Anyway, just a few ideas to discuss. Have at it. > > Cheers, > Matt > -- > Neo4j Chief Solutions Architect >
