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

[#1]

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?

[#2]

@Felix Albani @Timothy Spann can you please help me with this?

[#3 · Accepted solution]

@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.

[#4]

@Matt Clarke

so the only way to add new users is to login to NiFi as admin and then add the users via UI?

[#5]

@Harish Vaibhav Kali

Yes, unless you are using ldap and can setup a ldap sync to add the users for you.

[#6]

@Matt Clarke

Hi Matt,

Let's say if I have a list of users that have access to an instance of NiFi. Is there any way I can retain those users even after I re-install NiFi on that particular instance?

[#7]

@Harish Vaibhav Kali

Are we still talking about users created in a NiFi 0.x version being used in a NiFi 1.x+ version?
How user authorization is handled is different between each of those major release versions.

-

Lets assume you are working with purely NiFi 1.x+ versions.
There are three tightly couple files when it comes to user authorization (assuming you are using NiFi default file based authorizer):

1. users.xml <-- contains all user to which authorizations will be granted. Each user is assigned a unique UUID.

2. Authorizations.xml <-- Contains all authorization policies (some policies will be based off specific components uuids) User UUIDs are associated to one or more policies.

3. flow.xml.gz <-- contains all components add to NiFi and their configurations

-

So saving off these three files before your re-install your NiFi instance will allow you to put them back afterwards. Keep in mind that sensitive properties (i.e - passwords) in the flow.xml.gz file are encrypted using the sensitive props key set in the nifi.properties file. So you must use same sensitive props key on re-installed NiFi version or NiFi will fail to start because it cannot decrypt the sensitive props.

-

Thanks

Matt

[#8]

Hi Matt,

I know that when the users are added via NiFi UI, it reflects in the users.xml file. What I am asking is, if suppose I have added 10 users via NiFi UI and now I have 10 users in my users.xml file. So now can I use this users.xml file in future installations. If suppose I use the same users.xml in a new installation, will those 10 users be able to login to the newly installed NiFi?

[#9]

@Harish Vaibhav Kali

-

The users.xml only contains all the users and the UUID each has been assigned. It has nothing to do with authorizations for those users. While you can copy the users.xml file to another NiFi install which will result in those 10 users existing in that new NiFi, the authorizations for those 10 users will not exist on new server since the actual authorizations are stored in the authorizations.xml file.

-

Thanks,

Matt

[#10]

@Matt Clarke

So is there any way I can migrate the users I added manually via UI in one installation of NiFi to a different installation?

If so, how?

The reason I am asking this is because, I dont want to manually add the users everytime I reinstall NiFi

[#11]

@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

[#12]

@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?

[#13]

@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.

[#14]

@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

[#15]

@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.

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.