There are of course UI/UX improvements to be made but as a rough concept, I really like the idea. It reminds me a lot of the origin story of NiFi; where instead of having to map out the dataflow in Visio-like program each time a manager wanted to see the current flow (and it'd be outdated an hour later), the tool was self-documenting. This way the security policies of the dataflow would be self-documenting as well.
Security is integral to NiFi itself so giving the option to visualize the security policies as a first class citizen would be a great new feature. - Joe On Wed, Jan 18, 2017 at 6:16 PM, larry mccay <[email protected]> wrote: > That seems like a really interesting integrated visualization of security > concerns! > You would still need the complexities in the definition of the "security > zone" I imagine. > > > On Wed, Jan 18, 2017 at 3: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 >> >> > -- *Joe Percivall* linkedin.com/in/Percivall e: [email protected]
