I understand the desire to simplify NiFi security boundaries to make them both understandable and enforceable. I agree this is a worthwhile effort. However, I feel like we should acknowledge that this will effectively end multi-tenant authorization to different parts of a flow.
I know the NIP-39 says "Authorization for other Resource Types, such as Provenance, Data Content Viewing, Tenants, and Policies, should be unchanged" but in this regard I don't agree. I don't see the value of component-level fine-grained authorization for only some resource types but not all. It would be hard to explain the motivation behind what's allowed and what isn't. For example, I think this NIP proposes to allow: "You can restrict who can empty flowfile queues in this Process Group, but you cannot restrict who can modify/operate processors in this Group". I wouldn't be able to answer "Why?" So, at the end of this effort, would flow-level Policies go away and only controller-level Policies remain? I'm considering policies applied to Parameter Providers and the other "Management" components to be in the category of controller-level Policies. Thanks, -- Mike Moser On Fri, Aug 14, 2026 at 10:48 AM David Handermann < [email protected]> wrote: > Mark, > > Thanks for the thoughtful reply and concurrence with the approach. I > agree that more focused deployments provide a better security surface > in general, eliminating some of the earlier motivation behind the > attempts to provide fine-grained authorization. > > I will leave this discussion open until Monday and then start a vote > thread. > > Regards, > David Handermann > > On Wed, Aug 12, 2026 at 3:56 PM Mark Payne <[email protected]> wrote: > > > > Thanks David. This is one of those proposals that sounds, on the > surface, almost like we’re going backward. But I absolutely 100% agree with > this direction. First and foremost of the reasons outlined in the > “Motivation” section of the NIP. But even beyond that, I think it’s worth > noting that the typical NiFi deployment today is VERY different than it was > when the fine-grained access control was initially released. At that time, > the typical deployment footprint was huge, with large enterprises running 1 > or a handful of big NiFi clusters that span 32+ core machines. The > fine-grained approach alleviated the need for many instances based on > security controls. But today, we see many smaller deployments, and those > smaller deployments fall much more cleanly into those security boundaries. > And to me that alone may be enough to justify making these changes as well. > +1 from me. > > > > Thanks > > -Mark > > > > > > > > > On Aug 12, 2026, at 4:33 PM, David Handermann < > [email protected]> wrote: > > > > > > Team, > > > > > > I have drafted NIP-39 [1] proposing a simplified approach to framework > > > authorization for the REST API. > > > > > > This proposal follows along from the more focused proposal, NIP-24 [2] > > > that deprecated the Restricted component annotation for removal. > > > > > > The Controller-Level Authorization strategy aims to align implemented > > > capabilities with enforceable security boundaries. This approach would > > > eliminate the current mismatch between fine-grained authorization > > > configuration and full control over the system through Processors and > > > other extension components. > > > > > > Regards, > > > David Handermann > > > > > > [1] https://issues.apache.org/jira/browse/NIP-39 > > > [2] https://issues.apache.org/jira/browse/NIP-24 > > >
