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 >
