Mike, Thanks for the reply. I agree with you that the other Resource Types should also be included in this change for consistency, ending the multi-tenant authorization strategy for these Resources. I had originally considered decoupling the approach from those other Resource Types, but the argument for making a change across the board applies to those as well.
I adjusted the wording of that sentence to read: "Authorization for other Resource Types, such as Provenance, Data Content Viewing, Tenants, and Policies, should also be moved to the Controller level for consistency." To that end, yes, Policies for other types of extensions should also be limited to the Controller level. The above sentence was not intended to be exhaustive, but I'm glad to clarify it if that would be helpful. Regards, David Handermann On Mon, Aug 17, 2026 at 3:18 PM Michael Moser <[email protected]> wrote: > > 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 > > > > >
