Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

NiFi v0.6.1 vs NiFi v1.5.0 - Provide access to users via NiFi UI

avatar
Contributor

Hi,

I am currently working on upgrading NiFi from v0.6.1 to v1.5.0.

One thing I noticed is that in v0.6.1, when a user tries to login to NiFi and doesn't have permissions to login, he will be routed to a new justification window as below and will be asked to provide justification for access. Once he provides justification, the user's username will be added to the list of users in NiFi UI saying that the request is pending. The admin can then login and provide the access to that user.

But in v1.5.0, when a user with insufficient permissions tries to login to NiFi, the UI is routed to a new window which says Insufficient Permissions but does not add the user id to the list of users for the admin to process the request.

Was this feature removed in latest versions of NiFi?

If so, why was it removed? If not, how can I enable it in v1.5.0?

1 ACCEPTED SOLUTION

avatar
Super Mentor
@Harish Vaibhav Kali

-

With the release of Apache NiFi 1.0 there were major design changes to NiFi at its core.

Most obvious major changes include:

1. Gone is the NiFi Cluster Manger in favor of a new zero master clustering for example.
2. Additionally NiFi's authorization model moved to a very granular authorization setup and also added multi-tenancy capability (Multiple users can be logged in at the same time making changes concurrently to different components).

-

With this major re-work to user authentication/authorization the ability to request access was left out. Because of the new very granular authorization capability the notion of user requesting access became very convoluted. Suppose a user does have access to the /flow NiFi resource. This does not mean they have the ability to actually build, view, or modify any of the actual components on the canvas. And there is not capability for that user (who ha authorized access to the UI) to request additional accesses. So it felt just like an incomplete solution just to give only user who could not access UI ability to request access.

-

Not to say that such a capability may not come back in the future, i just believe it is a low priority type item.

-

As of Apache NiFi 1.5, Nifi provides the ability within the authorizers.xml to sync NiFi's list of users/groups with LDAP. This will auto populate users in the NiFi users UI to which an admin user can then apply various authorizations.

-

Thank you,

Matt

-

When an "Answer" addresses/solves your question, please select "Accept" beneath that answer. This encourages user participation in this forum.

View solution in original post

14 REPLIES 14

avatar
Super Mentor

@Harish Vaibhav Kali

-

You can copy the users.xml from one Nifi to another new NiFi installation without needing to edit it all assuming target is a standalone NiFi install.

-

Things become more complicated when your new installation is a NiFi cluster since the users.xml file you are copying over will contain user identifiers for the nodes on the original cluster it was copied form and not the new cluster. This would require you to hand edit the users.xml file before you could use it on new cluster will proper "identity" for each Nifi server in new cluster.

-

While this will add all the users from this users.xml file, there will only be authorizations setup for the user who was configured as the "initial admin identity" in authorizers.xml (that user must exist in the users.xml you copied over) and authorizations for the nodes "Node Identity <num>" in authorizers.xml (nodes must exist in copied over users.xml prior to starting NiFi).

-

You could also use the NiFi rest-api to add user on a new NiFi installation using the initial admin credentials to do so via the /nifi-api/tenants/users rest-api endpoint.

-

The least painful method is using NiFi's ldap sync capability to sync user/groups from ldap. Then there is no need to copy over a users.xml. All users would just come from ldap and an admin could simply assign the user authorization polices as needed.

-

thanks,

Matt

avatar
Contributor

@Matt Clarke

Is it required to set the access policies(view component, modify component, view the data, modify the data, etc.) for the main process group to configure the flows every time a new instance of NiFi is installed?

I am able to start NiFi and login to the UI. After starting NiFi, when I am trying to configure the flows, it gives me error saying: HTTP call failed. Status code: HTTP/1.1 403 Forbidden: No applicable policies could be found. Contact the system administrator.

When I login to NiFi and manually link access policies to admin and then try to configure the flows, it works fine.

So do I have to link the access policies to admin every time I install an instance of NiFi for configuring the flows?

avatar
Super Mentor

@Harish Vaibhav Kali

-

The authorization policies are very granular. Setting policies to view and modify component and view and modify data on a process group will be inherited by all components and sub-process groups created within that process group.

-

Keep in mind that the root level canvas you see when you log in to a new install is just another process group (root process group).

-

Applicable polices must be granted to the logged in user in order for that user to perform the desired action. Admin user does not need policies to specific flow components in order for other users to perform actions based on authorizations those other users have been granted.

avatar
Super Mentor

@Harish Vaibhav Kali

-

This thread is kinda moving off topic form the original question which has been answered. It is probably best to start a new question.

-

That being said, what you are showing me looks to be correct functionality provided the following is true:

---> When NiFi was started for the first time there was no pre-existing flow.xml.gz.

For a brand new secure flow, providing the "Initial Admin Identity" gives that user access to get into the UI and to manage users, groups and policies. But if that user wants to start modifying the flow, they need to grant themselves policies for the root process group. The system is unable to do this automatically because in a new flow the UUID of the root process group is not permanent until the flow.xml.gz is generated. If the NiFi instance is an upgrade from an existing flow.xml.gz or a 1.x instance going from unsecure to secure, then the "Initial Admin Identity" user is automatically given the privileges to modify the flow.

-

Also keep in mind that if the users.xml and authorizations.xml files do not exist and you have configured both the "initial admin Identity" and provided a legacy "authorized-users.xml" file, Nifi will fail to start. That is because the initial seeding of the users.xml and authorizations.xml files can be done via one or the other, but not both.

-

Thank you,

Matt

avatar
Contributor

@Matt Clarke

But everytime I install NiFi and login as admin, I see the root process group and when I click the Access Policies(Key symbol) button on NiFi root level, it opens the access policies dialog and it there it says "No policy for the specified resource. Create a new policy."

Now when I click create a new policy and add the admin, I am able to configure flows or else it gives me error mentioned in the above comment.

83504-access-policies-nifi.png

83505-access-policies-user-nifi.png

So, is this behavior expected or am I missing something? I have added the admin user in authorized-users.xml and mentioned that user as admin in Initial admin identity property in authorizers.xml as well.