Matt,
Option 2 is definitely the way we're headed. The custom authorizer utilizes
the file-based authorizer; it provides supplemental authorization when
adding a user to a policy, for example. However, it relies on the
authorizations.xml and users.xml files being correct when making
policy-based
Bryan,
I'm not sure building something similar to the
ProcessorInitializationContext is possible without changes to the framework
itself. The framework is responsible for instantiating the initialization
context - in both processor and authorizer. However, the
AuthorizationInitializationContext
Mark,
I think you have a couple options. First, just to provide a little more
detail for the basics of NiFi clustering with regards to
users/groups/policies. If you want to support _configurable_
users/groups/policies in NiFi UI then consistency is required. For
instance, if an admin wants to
Mark,
I don't believe there is currently anything like this in Authorizer API.
You would likely have to build something similar to what processors have...
In ProcessorInitializationContext they get access to a NodeType which
tells them if they are currently primary or not.
Then they can
Is there a way to get access to Cluster configuration state? Specifically,
can a Node determine which Node - or simply "itself" - is the Cluster
Coordinator or the Primary Node?
Use case: I have a custom authorizer which includes a background thread to
re-authorize users and policies in case a
