nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Percivall <jperciv...@apache.org>
Subject Re: [DISCUSS] Idea for visual access control policy application
Date Wed, 18 Jan 2017 23:38:25 GMT
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 <larry.mccay@gmail.com> 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 <alopresto@apache.org>
> 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
>> alopresto@apache.org
>> *alopresto.apache@gmail.com <alopresto.apache@gmail.com>*
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>>
>


-- 
*Joe Percivall*
linkedin.com/in/Percivall
e: jpercivall@apache.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message