So "functionality based security" is the same as "action based security". It's just another name. It's just that you have a "long-tail" sort of list of objects, actions and permissions to populate. While impossible to do everything at once it's easy to chip away at the list over time.
On Mon, Feb 15, 2021 at 3:49 PM Bart Maertens <[email protected]> wrote: > 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 > > >
