I cannot see the data in the queue, I'm in Nifi 1.5 into HDF 3.1

[#1]

I create a flow, and when I try to see the info in the queue, I get the follow message:

Node NODE2 is unable to fulfill this request due to: Unable to view the data for Processor with ID 4c303445-bbac-164d-0000-00002eb87bc3. Contact the system administrator. Contact the system administrator.

I got the administrator role, and neither can see the info. I test this with and without scheduled the processor to run in primary and all nodes, same answer.Also, when I try to empty queue, get the same answer

Any clues?

Regards

[#2 · Accepted solution]

Hi @Diego A Labrador

I believe you need to add the administrator to the "view the data" and "modify the data" access policies for the process group.

To be able to see or delete the queue from all connections, select the root process group and click the key icon from the Operate palette:

Then select the "view the data" from the Access Policies window drop-down and add your admin to that policy.

You should now be able to see the queue in the connection.

Similarly, add the admin to the "modify the data" policy to get empty privileges on the queue.

More info on these policies can be found:

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#component-level-access-policie...

[#3 · Accepted solution]

Hi @Diego A Labrador

I believe you need to add the administrator to the "view the data" and "modify the data" access policies for the process group.

To be able to see or delete the queue from all connections, select the root process group and click the key icon from the Operate palette:

Then select the "view the data" from the Access Policies window drop-down and add your admin to that policy.

You should now be able to see the queue in the connection.

Similarly, add the admin to the "modify the data" policy to get empty privileges on the queue.

More info on these policies can be found:

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#component-level-access-policie...

[#4 · Accepted solution]

@Diego A Labrador

-

In addition to making sure that your user has been granted "view the data", you will want to grant the same policy to all your NiFi nodes. When a user is logged in to node1 for example and request to list a queue. That request is replicated to all nodes. The other nodes will return the listing results to the node where the request originated. If the originating nodes has not been granted permissions to see data on other nodes it will not get displayed.

-

Thank you,

Matt

[#5]

Can you please share the reference on how "to grant the same policy to all your NiFi nodes"?

Context:  I am running NiFi 1.13.2 on 3 nodes.  Authorization is provided by LDAP group membership, so it covers human users to "view the data".  However, the error message is still complaining that "Nifi-node-0" has insufficient privilege to view the data.  

I am hoping a reference that covers how the "node name" is defined in a fully qualified way, so I can add these NiFi node names in the right syntax to satisfy this permission control.  Thanks. 

For reference:

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#component-level-access-policie...

The last paragraph referenced in this link identified this need, but there are no examples of actual fully qualified cluster nodes available.  For example, is this in some sort LDAP convention, using OU="nifi-node-1.company.com, CN=etc..." or in some other convention or way?   

[#6]

@data-light 

NiFi nodes will always be authenticated via the clientAuth certificate they present.  The Owner DN from the node's PrivateKeyEntry in the keystore file is what is used.  What is important to know is that NiFi provides a mechanism that can trim/modify those full DNs through the uses of identity mapping properties [1]that users can configure in the nifi.properties file.  After a mapping is applied against an identity string the resulting mapped value is what is actually passed to the configured NiFi Authorizer.

So within the authorizer, that now mapped value is what the authorization policies need to be mapped to.
The nifi-user.log will show the mapped value (case sensitive) that is being used during authorization.  So if you see only "Nifi-node-0" in the nifi-user.log, then that exact string is what needs to exist in your authorizer and have policy assigned to it.  If the nifi-user.log was showing "cn=Nifi-node-0, ou=mycompany, ou=nifi", then that full DN would need to be present in your authorizer with assigned policies.

So you will want to get a verbose output of your nodes keystore files, your nifi.properties file to see what identity mapping patterns have been set, and the authorizers.xml to see how your authorization setup is done, and the nifi-user.log. 

[1] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#identity-mapping-properties

Hope this helps address your question. IF so, please take a moment to login and click "Accept" on this solution.

Thank you,

Matt

[#7]

Thanks a lot @Matt Clarke, @Andrew Lim
Both of you are rigth, and to get a complete answer, let me organize this:

1.- The "user" has no privileges to view and modify the data.

2.- The "user" was, indeed, the other nodes in the cluster, because we are making adjustments related to policies and did not remember how was this user. After the problem we realize that and adding the nodes again.

3.- We are reading and adjusting the policies accordingly to the Apache Nifi documentation.

Regards