nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Farbota <jfarb...@payoff.com>
Subject Re: [DISCUSS] Idea for visual access control policy application
Date Wed, 18 Jan 2017 23:50:05 GMT
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 <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
>
>


-- 
*Jeremy Farbota*
Software Engineer, Data
Payoff, Inc.

jfarbota@payoff.com
(217) 898-8110 <+2178988110>

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