I like the concept although I agree with Rob Moran that this UX may not necessarily belong on the canvas. Rather, it could be a separate UX targeted at an admin type user. Maybe the admin would be able to drag/drop into the zones and 'configure' NiFi on a per user/group basis and then when a particular user visits the canvas they would get a tailored experience where they would be able to build a flow however they want but would only be able to access the components they have been 'configured' for...
On Thu, Jan 19, 2017 at 12:22 PM, Russell Bateman <[email protected]> wrote: > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> [email protected] >>>>> *[email protected] <[email protected]>* >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>>>> >>>>> On Jan 18, 2017, at 3:50 PM, Jeremy Farbota <[email protected]> >>>>> >>>> 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 <[email protected]> >>>>> 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. >>>>>> >>>>>> Very interested in feedback from the group at large. Could just be a >>>>>> wild goose chase and there are better solutions out there. >>>>>> >>>>>> [1] https://issues.apache.org/jira/browse/NIFI-3370 >>>>>> [2] https://issues.apache.org/jira/browse/NIFI-3115 >>>>>> >>>>>> >>>>>> Andy LoPresto >>>>>> [email protected] >>>>>> *[email protected] <[email protected]>* >>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> *Jeremy Farbota* >>>>> Software Engineer, Data >>>>> Payoff, Inc. >>>>> >>>>> [email protected] >>>>> (217) 898-8110 <+2178988110> >>>>> >>>>> >>>>> >>>>> > -- *Scott Aslan = new WebDeveloper(* *{ "location": { "city": "Saint Cloud", "state": "FL", "zip": "34771" }, "contact": { "email": "[email protected] <[email protected]>", "linkedin": "http://www.linkedin.com/in/scottyaslan <http://www.linkedin.com/in/scottaslan>" }});*
