Re: [DISCUSS] Idea for visual access control policy application

[Russell Bateman]

Telescopic then that there might be flow one has no access to see as 
well as other flow one can see but not change? Then do we have flow to 
which one can add, but not subtract, etc.? Can one detach from a 
protected flow? Can one stop/start protected flows? If a protected flow 
cannot be stopped, then one cannot insert before or add to it after. Etc.


It gets creepy ugly, but I suppose if it can be represented and 
manipulated visually... What a challenge!


Russ

On 01/19/2017 09:20 AM, Rob Moran wrote:

If I'm understanding how this security zone concept would work, I think
making decisions about the placement of components on the canvas according
to authorization would introduce a lot of confusion around understanding
the data flow itself and how it is supposed to work.

To me a big part of access policy management that NiFi lacks is the ability
to think about it from an individual user/user group perspective. That
would help those user(s) tasked with managing policies easily think about
and control "what Matt can see and do" and "what the HR group can see and
do."

Perhaps a more engaging UI with drag and drop capabilities would be useful
to help manage it. There I could see the concept of security zones or
profiles (roles?) to help. I'm all for exploring those options, but I think
that experience should happen outside the canvas and not influence
decisions made when building a data flow.

Rob

On Thu, Jan 19, 2017 at 9:33 AM, Matt Gilman 
wrote:


Thanks for starting this DISCUSS. This is definitely an area that we need
to continue improving.

The concept of a security zone seems like it could be implemented using a
Process Group. However, if I'm following along the difference being that
the security zone does not visually hide encapsulated components. Koji's
comment about allowing components to share a security zone but not be
co-located is interesting as well. Continuing down this thought process,
defining security zones using a selector-like mechanism would allow the
security zones to automatically update (kind of like a smart playlist).

Definitely some good ideas here. As we continue to introduce these sorts of
efficiencies we'll need to ensure we have a rock solid UX to ensure there
is no ambiguity regarding the component policies at any point in time.

Matt

On Wed, Jan 18, 2017 at 8:50 PM, Koji Kawamura 
wrote:


Hi Andy,

I like this idea, too! Enabling security policy for multiple components

is

definitely useful.

While I was thinking about the security zone concept, I was wondering if
components those share the same level of security policy stay close in 2
Dimensional position on a flow. Maybe those components would scatter

around

in a flow, and it'd be hard to put them in a single rectangle area.

One alternative approach to apply policy to components came up.
That is managing components by adding TAGs or Classes as such in CSS

class.

Then like CSS, specify policies to a particular class. We will also able
to alter visual style on NiFi flow based on the style.

Just an idea, but wanted to share.

Thanks,
Koji


On Thu, Jan 19, 2017 at 9:49 AM, Andy LoPresto 
wrote:


Thanks for the feedback so far. I don’t want to cut off conversation
here, I just wanted to see if this was worth exploring further and it

seems

it is. I would love to hear additional input from (among others) Andre

Fucs

de Miranda and Anders Braindahl who have both offered really valuable
security insight in the past, Matt Gilman who is the Oracle of NiFi

policy,

and Rob Moran who would know how to make this actually look appealing

and

work the way users expect.

I’ll open a ticket for this to facilitate further conversation and make
it trackable.

Andy LoPresto
alopre...@apache.org
*alopresto.apa...@gmail.com *
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jan 18, 2017, at 3:50 PM, Jeremy Farbota 

wrote:

I like this idea. I like moving some of the security controls into the
UI. Using this with Process Groups would be an adequate level of
granularity for me. I think this would add a lot of value to the UI and
adding security policy controls to UI enables super users to manage the
security without needing root access on the server. This could simplify

the

process of recreating NiFi environments because you can see the security
policies in the UI instead of needing to look at the configs.

On Wed, Jan 18, 2017 at 12:38 PM, Andy LoPresto 
wrote:


I just opened NIFI-3370 [1] for “apply access control polices
simultaneously to multiple selected components” and related it to a
previous large ticket NIFI-3115 [2] “enhance user policy management
functionality” with a grab bag of thoughts I had on that. I had another
idea for this but it’s a little out of left field so I wanted to get

some

community feedback before I opened a ticket and see if 

Re: [DISCUSS] Idea for visual access control policy application

[Rob Moran]

If I'm understanding how this security zone concept would work, I think
making decisions about the placement of components on the canvas according
to authorization would introduce a lot of confusion around understanding
the data flow itself and how it is supposed to work.

To me a big part of access policy management that NiFi lacks is the ability
to think about it from an individual user/user group perspective. That
would help those user(s) tasked with managing policies easily think about
and control "what Matt can see and do" and "what the HR group can see and
do."

Perhaps a more engaging UI with drag and drop capabilities would be useful
to help manage it. There I could see the concept of security zones or
profiles (roles?) to help. I'm all for exploring those options, but I think
that experience should happen outside the canvas and not influence
decisions made when building a data flow.

Rob

On Thu, Jan 19, 2017 at 9:33 AM, Matt Gilman 
wrote:

> Thanks for starting this DISCUSS. This is definitely an area that we need
> to continue improving.
>
> The concept of a security zone seems like it could be implemented using a
> Process Group. However, if I'm following along the difference being that
> the security zone does not visually hide encapsulated components. Koji's
> comment about allowing components to share a security zone but not be
> co-located is interesting as well. Continuing down this thought process,
> defining security zones using a selector-like mechanism would allow the
> security zones to automatically update (kind of like a smart playlist).
>
> Definitely some good ideas here. As we continue to introduce these sorts of
> efficiencies we'll need to ensure we have a rock solid UX to ensure there
> is no ambiguity regarding the component policies at any point in time.
>
> Matt
>
> On Wed, Jan 18, 2017 at 8:50 PM, Koji Kawamura 
> wrote:
>
> > Hi Andy,
> >
> > I like this idea, too! Enabling security policy for multiple components
> is
> > definitely useful.
> >
> > While I was thinking about the security zone concept, I was wondering if
> > components those share the same level of security policy stay close in 2
> > Dimensional position on a flow. Maybe those components would scatter
> around
> > in a flow, and it'd be hard to put them in a single rectangle area.
> >
> > One alternative approach to apply policy to components came up.
> > That is managing components by adding TAGs or Classes as such in CSS
> class.
> > Then like CSS, specify policies to a particular class. We will also able
> > to alter visual style on NiFi flow based on the style.
> >
> > Just an idea, but wanted to share.
> >
> > Thanks,
> > Koji
> >
> >
> > On Thu, Jan 19, 2017 at 9:49 AM, Andy LoPresto 
> > wrote:
> >
> >> Thanks for the feedback so far. I don’t want to cut off conversation
> >> here, I just wanted to see if this was worth exploring further and it
> seems
> >> it is. I would love to hear additional input from (among others) Andre
> Fucs
> >> de Miranda and Anders Braindahl who have both offered really valuable
> >> security insight in the past, Matt Gilman who is the Oracle of NiFi
> policy,
> >> and Rob Moran who would know how to make this actually look appealing
> and
> >> work the way users expect.
> >>
> >> I’ll open a ticket for this to facilitate further conversation and make
> >> it trackable.
> >>
> >> Andy LoPresto
> >> alopre...@apache.org
> >> *alopresto.apa...@gmail.com *
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >> On Jan 18, 2017, at 3:50 PM, Jeremy Farbota 
> wrote:
> >>
> >> I like this idea. I like moving some of the security controls into the
> >> UI. Using this with Process Groups would be an adequate level of
> >> granularity for me. I think this would add a lot of value to the UI and
> >> adding security policy controls to UI enables super users to manage the
> >> security without needing root access on the server. This could simplify
> the
> >> process of recreating NiFi environments because you can see the security
> >> policies in the UI instead of needing to look at the configs.
> >>
> >> On Wed, Jan 18, 2017 at 12:38 PM, Andy LoPresto 
> >> wrote:
> >>
> >>> I just opened NIFI-3370 [1] for “apply access control polices
> >>> simultaneously to multiple selected components” and related it to a
> >>> previous large ticket NIFI-3115 [2] “enhance user policy management
> >>> functionality” with a grab bag of thoughts I had on that. I had another
> >>> idea for this but it’s a little out of left field so I wanted to get
> some
> >>> community feedback before I opened a ticket and see if people thought
> it
> >>> was a good idea or too confusing/unnecessary.
> >>>
> >>> Imagine the concept of “security zones” on the canvas. I diagrammed
> >>> these with labels currently, but we could obviously modify the

Re: [DISCUSS] Idea for visual access control policy application

[Matt Gilman]

Thanks for starting this DISCUSS. This is definitely an area that we need
to continue improving.

The concept of a security zone seems like it could be implemented using a
Process Group. However, if I'm following along the difference being that
the security zone does not visually hide encapsulated components. Koji's
comment about allowing components to share a security zone but not be
co-located is interesting as well. Continuing down this thought process,
defining security zones using a selector-like mechanism would allow the
security zones to automatically update (kind of like a smart playlist).

Definitely some good ideas here. As we continue to introduce these sorts of
efficiencies we'll need to ensure we have a rock solid UX to ensure there
is no ambiguity regarding the component policies at any point in time.

Matt

On Wed, Jan 18, 2017 at 8:50 PM, Koji Kawamura 
wrote:

> Hi Andy,
>
> I like this idea, too! Enabling security policy for multiple components is
> definitely useful.
>
> While I was thinking about the security zone concept, I was wondering if
> components those share the same level of security policy stay close in 2
> Dimensional position on a flow. Maybe those components would scatter around
> in a flow, and it'd be hard to put them in a single rectangle area.
>
> One alternative approach to apply policy to components came up.
> That is managing components by adding TAGs or Classes as such in CSS class.
> Then like CSS, specify policies to a particular class. We will also able
> to alter visual style on NiFi flow based on the style.
>
> Just an idea, but wanted to share.
>
> Thanks,
> Koji
>
>
> On Thu, Jan 19, 2017 at 9:49 AM, Andy LoPresto 
> wrote:
>
>> Thanks for the feedback so far. I don’t want to cut off conversation
>> here, I just wanted to see if this was worth exploring further and it seems
>> it is. I would love to hear additional input from (among others) Andre Fucs
>> de Miranda and Anders Braindahl who have both offered really valuable
>> security insight in the past, Matt Gilman who is the Oracle of NiFi policy,
>> and Rob Moran who would know how to make this actually look appealing and
>> work the way users expect.
>>
>> I’ll open a ticket for this to facilitate further conversation and make
>> it trackable.
>>
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com *
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>> On Jan 18, 2017, at 3:50 PM, Jeremy Farbota  wrote:
>>
>> I like this idea. I like moving some of the security controls into the
>> UI. Using this with Process Groups would be an adequate level of
>> granularity for me. I think this would add a lot of value to the UI and
>> adding security policy controls to UI enables super users to manage the
>> security without needing root access on the server. This could simplify the
>> process of recreating NiFi environments because you can see the security
>> policies in the UI instead of needing to look at the configs.
>>
>> On Wed, Jan 18, 2017 at 12:38 PM, Andy LoPresto 
>> wrote:
>>
>>> I just opened NIFI-3370 [1] for “apply access control polices
>>> simultaneously to multiple selected components” and related it to a
>>> previous large ticket NIFI-3115 [2] “enhance user policy management
>>> functionality” with a grab bag of thoughts I had on that. I had another
>>> idea for this but it’s a little out of left field so I wanted to get some
>>> community feedback before I opened a ticket and see if people thought it
>>> was a good idea or too confusing/unnecessary.
>>>
>>> Imagine the concept of “security zones” on the canvas. I diagrammed
>>> these with labels currently, but we could obviously modify the appearance
>>> sufficiently (forgive the screenshot; I was in the middle of reviewing a PR
>>> that doesn’t include restricted processors, nor was it secured). The zone
>>> gets one or more policies defined (in my example “Not accessible by Matt”
>>> or “Accessible only by HR group”) and then components can be dragged
>>> into/out of the zone by an authorized user. Once a component is in the zone
>>> (and snapping would be enabled to remove ambiguity about what is in or out
>>> if it overlaps), it inherits the policies defined by that zone. The
>>> policies could be marked by origin (inherited from zone, applied manually,
>>> etc.) and there is an audit log, so if the component is dragged out of the
>>> zone, any policies only inherited from that zone could be removed and it
>>> would “re-inherit” just the root policies. For only one or two components,
>>> it doesn’t save much time, but you could drag snippets, flow sections, and
>>> process groups in and out of the zone.
>>>
>>> I think this would make visual assignment and recognition of (sometimes
>>> complex) policies much easier, and greatly reduce the amount of dialogs and
>>> searches that occur.