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 > >
