Hi All, There is a big difference between application security and system security. I do agree that we need to take into account a bit of the system security part but as a project this should not be the main focus. From the project perspective the application should be able to ingest username and a role and map this to certain features/actions/... to limit the possibilities for that role. It should be implemented in such a way that the most common authentication providers can pass the authorization to the application. I do not think we are at a point where we wan't to include a "real" authentication provider. We should add a default password provider to Hop Web, but larger corporations will have their own needs/systems/setup to deploy the end product.
For example the use case Hiromu is mentioning is valid, maybe they want a container per user authenticating. But the implementation for this should not be done by us as it is platform/cloud/system specific. It would require building a complete management system for Hop Web/Authentication Providers and Kubernetes. To come back to the subject, what I have seen in the field is that there are projects where multiple users share a large cloud instance to do development on, Hop Web is the perfect alternative for this but I would also like the ability to pass a java parameter to hop-gui to split the user sessions. this could be done by either adding a variable in the user space or passing it as a parameter in the hop-gui Cheers, Hans On Tue, Feb 16, 2021 at 8:38 AM Hiromu Hota <[email protected]> wrote: > Hi all, > > Sorry for keeping you waiting for Hop Web to be merged to the upstream. > As Matt mentioned, the most part of it has been merged and now hop.war file > is now built daily by the CI server. > > Here is my opinion around security and locking on the Hop Web. > IMO, it'd be better to dedicate a Hop Web instance to a single user. > By doing this, we don't have to worry about locking and acl, hence we don't > have to introduce additional complexities to the codebase that is already > getting complicated due to the single-sourcing between Hop GUI (RCP/SWT) > and Hop Web (RAP/RWT). > Now that we have Docker/K8S, it is much easier to deploy instances as > needed. > > Regarding user-auth and other security measures like HTTPS, we know that > there are many possible patterns in doing these and totally up to users. > IMO, we can just let users do any of these outside an Hop Web instance as > a reverse-proxy. > Again, this can keep the codebase simple yet provides flexibility to users. > > Thanks, > Hiromu > > On Mon, Feb 15, 2021 at 2:33 AM Matt Casters <[email protected] > .invalid> > 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 > > >
