[DISCUSS] Security, Locking, ...

[Matt Casters <ma...@neo4j.com.INVALID>]

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 some.user@gmail.com 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

Re: [DISCUSS] Security, Locking, ...

[Brandon Jackson <us...@gmail.com>]

There are several layers of security and permissions to take into
consideration.
* Docker and how it behaves on the host system running the container which
contains webhop
* Tomcat and the mechanisms providing authentication of the webhop session
that is shared between the tomcat server and the users' browser.

A guide for some of this would be that if there is to be a long running
container that acts like a server that people want to start, stop and
resume, you will want to be careful that all file writes or updates end up
on a shared volume or bind mount that docker provides to the container
running webhop.  This means everything, from tmp, caching, logs, audit,
configurations, environments and finally user content.  If anything gets
missed, these writes will appear as additional 'overlay' layers written to
the virtual disk inside the container and usually stored in the root file
system of the host computer.  It will continue to grow over time until the
container is completed wiped from the host.  This is less of a problem if
you have throw away containers where they are started with --rm where when
they stop they clean up after themselves.

Another thing to consider from the docker side is, which user webhop runs
as inside the container.   When containers move between environments, they
carry over some of the traits from the environment where they were
created.  For example, if you have a build system where root is user 0 and
then create a user called webhop with a user ID and GID of say 1001 on the
build system, if you then use that user to add or create files, that user
ID and GID are saved in the resultant image.  When an external user picks
up the image and pulls it to their host system, there may be a mismatch of
that non-privileged user, which will give you all sorts of access denied
behavior.  That behavior is really bubbling up from the host operating
system when the container runs. It might be necessary to create a user with
a high user ID range and group ID that would be safe for most container
users to also create on their host systems to avoid problems like that and
still remain secure.

Once you are sure there are no docker host / Linux related permission
issues, the rest of the security with Tomcat can be handled using whatever
mechanisms you think are adequate.  I would think maybe some safe default
modes by using internal tomcat user security that could be injected into
the container at startup.  The only other security framework I am familiar
with is Spring from the taho days.

I hope this helps.

Brandon




On Mon, Feb 15, 2021 at 4:33 AM Matt Casters <ma...@neo4j.com.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 some.user@gmail.com 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
>

Re: [DISCUSS] Security, Locking, ...

[Hans Van Akelyen <ha...@gmail.com>]

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 <hi...@gmail.com> 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 <matt.casters@neo4j.com
> .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 some.user@gmail.com 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
> >
>

Re: [DISCUSS] Security, Locking, ...

[Hiromu Hota <hi...@gmail.com>]

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 <ma...@neo4j.com.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 some.user@gmail.com 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
>

Re: [DISCUSS] Security, Locking, ...

[Matt Casters <ma...@neo4j.com.INVALID>]

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 <ba...@know.bi> 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
> <ma...@neo4j.com.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 some.user@gmail.com 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
> >
>

Re: [DISCUSS] Security, Locking, ...

[Bart Maertens <ba...@know.bi>]

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
<ma...@neo4j.com.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 some.user@gmail.com 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
>