Support Questions

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

Error : Unable to perform the desired action due to insufficient permissions.

avatar
Rising Star

I followed the instructions here : How To Create User Generated Keys for Securing Nifi

...and after some initial problems I have a single user account working. This is the account I placed into the "authorizers.xml" file within the "Initial Admin Identity". The person with that SSL cert can access the system just fine.

My question is how do subsequent users gain authorization? In the past (version .6) I recall they could connect and there was a request access process whereby the admin assigned roles to the new user. However, I handed out a 2nd cert (with a different email address) to a co-worker and they are simply getting the error "Unable to perform the desired action due to insufficient permissions" in their browser when trying to connect.

Do I need to add their info to a file before they can access Nifi?

Are there still roles? Via the authorizations.xml file there appears to still be roles, but I am not clear how they are assigned.

When my coworker attempts to access, here is the the nifi-user.log entry:

INFO [NiFi Web Server-173] o.a.n.w.a.c.AccessDeniedExceptionMapper EMAILADDRESS=<users.email@company.com>, CN=myservernode1, OU=NIFI, O=BU, L=ST, ST=MD, C=US does not have permission to access the requested resource. Returning Forbidden response.

Thanks, again, for any assistance.

1 ACCEPTED SOLUTION

avatar
Master Guru

In 1.x the initial admin can grant access to the other users through the UI by adding a user from the global menu in the top-right and creating a user with the DN of their cert, then give that user access to the resources they should be able to access (i.e. the root group or a individual process group).

There are no more true roles in 1.x, although you can simulate them using groups, but in general everything on the canvas can have a policy that defines the users or groups who can take action on it.

View solution in original post

5 REPLIES 5

avatar
Master Guru

In 1.x the initial admin can grant access to the other users through the UI by adding a user from the global menu in the top-right and creating a user with the DN of their cert, then give that user access to the resources they should be able to access (i.e. the root group or a individual process group).

There are no more true roles in 1.x, although you can simulate them using groups, but in general everything on the canvas can have a policy that defines the users or groups who can take action on it.

avatar
Rising Star

Interestingly enough, it did not work until I stopped and restarted nifi.

I did take the user's id ("user identifier") out of the users.xml file and add that ID to the policies within authorizations.xml. Not certain that was needed or not? Do those policies work similar to the old roles?

avatar
Super Mentor

@marksf

I recommend against hand editing the users.xml and authorizations.xml files.

You should be adding additional users and granted appropriate access policies via the NiFi UI instead.

The below image covers where to add new users and how to set both global and component level access policies.

12426-screen-shot-2017-02-02-at-112254-am.png

At a minimum, all users added to nifi must be granted the Global "access policy" for "view the user interface" before they can access the NiFi UI. Other policies will allow user to interface with various features/capabilities within the UI.

Matt

avatar
Master Guru

Yes I agree with Matt... once the initial admin has access to the UI, there should be no hand-edits to users.xml or authorizations.xml, everything should be done from the UI.

avatar
Rising Star
@Matt Clarke

- I think I get it now. I was misunderstanding that within the Policy area I need to literally add their cert credentials. I was falsely assuming once I added a user, I would see those users as options to add to policies. It appears I must not only copy the users cert to the users area but also to all of the policies to which they should have access.

I agree, I did not want to manually edit files. I was just previously confused how policies were getting applied.