@zzzz77
Apache NiFi use to be by default unsecured when launched without setting up security manually. The expectation was that the end user of Apache NiFi would take steps to secure the NiFi before using it for production use cases to protect sensitive data. More recently the Apache Community decided to have NiFi Start securely out of the box. This was partly for two reasons. First to avoid users from accidentally exposing sensitive information by have their NiFi running wide open to anyone who can access the url. Secondly, most modern browser now force users to https://.... when an http://.. . address is supplied. The out-of-the-box secure setup provides very minimal security. It generates self-signed certificate so that TLS/SSL https can be used and it utilizes a new "Single User" authentication and "Single User Authorizer".
This single user authorizer give the generated single user full access to the NiFi. There is no way to create additional users or modify authorizations when using this authorization provider. It's intended use is to provide a secure NiFi out-of-the-box for ease of product evaluation. For a more robust multi-user NiFi deployment different user authentication and Authorization provider need to be used. Also recommend generating/obtaining properly signed certificates for your NiFi instance(s).
LDAP is probably the most commonly used for authentication through the "ldap-provider" since NiFi does not have a multi-user local provider option. You can find all authentication provider options in NiFi in teh admin guide under: User Authentication
With a change to the authentication provider, you will also need to setup a multi-user authorizer so you can manage the authorization for your ldap user identities. You can find option in the admin guide under Multi-Tenant Authorization. Most common setup typically utilizes the Managed-Authorizer, File-Access-Policy-Provider, Composite-Configurable-User-Group-Provider, File-User-Group-Provider, and LDAP-User-Group-Provider.
In your File-Access-Policy-Provider, you'll be able to define who your "initial admin" user will be. This would typically be one of your ldap users. This provider on first launch will generate a authorizations.xml file that will contain the minimum required authorization required for the admin user. NOTE: the initial admin does not get access granted to everything; however, will have ability to granted all additional authorizations the admin user may want and to setup authorizations for all other users.
The admin guide also covers the various authorization policies here: Configuring Users & Access Policies
NiFi authorizations are very granular.
You can set unique policies for each user if you want.
EVERY user must be authorized for "view the user interface" or the user will not be able to access the UI. The admin user can optionally create a different process group on the NiGi UI for each team or person that will be building dataflows on the canvas. The Admin user then authorizes the team of person to the appropriate process group. This prevents one user/team form being able to view the configuration of another teams dataflow or modify another teams dataflows. They will only have access within their authorized process group. A user does not need to be an "Admin user" to build dataflows. What makes a user an admin is someone who can modify all policies, modify users, etc. Individual users can not modify authorizations or user and can still be granted ability to modify components so they can build dataflows within their admin authorized process group(s).
NOTE: All user can see where all components are placed on canvas tp prevent one team from building on top of another; however, those components for which a user is not aithorized will appear with dashed outlines and no details.
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
