@blackboks  Authentication and Authorization happen in two steps in NiFi and NIFi-Registry. Group association with Users is part of the Authorization step handled by the configuration in the authorizers.xml file. Authentication is step one which you have working. At the end of authentication all that is available and passed to for authorization is the User Identity.  In yoru case " nifi-admin-2@blackboks.ru " is what is being passed to the configured authorizer.    You are most likely using the managed-authorizer which utilizes the file-access-policy-provider which in turn has a dependency on one or more configurable user-group-providers (file-user-group-provider, ldap-user-group-provider, composite-user-group-provider, composite-configurable-user-group-provider).  It is these user group provider that are responsible for establishing what groups the user identity belongs to. What we can tell from the log output you shared is that your authorizer is unaware of any gorups that the user identity " nifi-admin-2@blackboks.ru " belongs to.   If the authorizer was aware of any groups associated to this user identity, those groups would have been in that log output instead of blank: identity[nifi-admin-2@blackboks.ru], groups[] So you'll need to verify the setup in your authorizers.xml and determine which user-group-provider you will use to establish these known user to group identity mappings. The file-user-group-provider would require you to do this manually from within the NiFi UI. Hopefully this helps clarify the why you are seeing what you are seeing. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@alan18080  The Single-User-Provider for authentication was not intended for production use. It is a very basic username and password based authenticator that support only a single user identity.  When you access the UI of a NiFi node, you are authenticating with only that node.  The provider generates a client token which your browser holds and a corresponding server side token/key held only by the node you authenticated with.    This is why you need to use sticky sessions (Session Affinity) in your load-balancer so that all subsequent request go to same NiFi server.  There is no option in NiFi that would allow that client JWT token to be accepted by all nodes in a NiFi cluster because of the uniqueness of the JWT generated token to a specific node. Related: NIFI-7246 Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@asand3r  Changing following to false turns off archiving. nifi.content.repository.archive.enabled NiFi does not clean-up files left in these directories once archive is disabled. Since archive is disabled the archive code that would scan these directories to remove old archive data is not longer executing.   You'll need to manually purge the archived content claims from the archive sub-directories after disabling content_repository archiving. So your two nodes that still have archive data had that data still present at shutdown while the others did not have archive data after shutdown. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@melek6199  When you setup an Apache NiFi cluster versus a standalone NiFi instance, the cluster coordinator and zookeeper become part of the setup.  Since a NiFi cluster is a zero master cluster, the UI can be access from any cluster connected node.  So your user authenticates to the specific node you are accessing and then that node proxies the user request (initially that would "access the flow") on behalf of that user to the cluster coordinator that replicates request to all connected nodes.    The exception means that node with node identity derived from certificate DN "CN=vtmrt3anifit04.x.com, OU=NIFI" was not properly authorized to "proxy user requests". All your NiFi node identities must be authorized to "proxy user requests". While it appears that your NiFi authorizers.xml is setup correctly with your 4 node's identities (case sensitivity also correct), I suspect it was only setup correctly after NiFi having already being started before it was configured correctly. The "file-access-policy-provider" will only generate the authorizations.xml during NiFi startup if it does NOT already exist.  It also will not modify an already existing authorizations.xml file. The "file-user-group-provider" will only generate the users.xml during NiFi startup if it does not already exist.  It also will NOT modify an already existing users.xml file. So I would inspect the users.xml to make sure it contains all 4 node identities (case sensitive correctly) and then verify the authorizations.xml has those node's properly authorized. So I would start here to make sure above is correct on all 4 nodes. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more