Support Questions

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

Authentication and authorization methods in apache NiFi

avatar
New Contributor

Greetings, everyone.
I'm kind of new to NiFi and trying to implement some simple authorization method that is not default (single-user). All I want to do is a couple static users with some permissions and login screen asking for credentials - 2 roots and 2 read-only will be more than enough for example.
I've tried to search for my answer in other topics both in cloudera and documentation, but didn't find any useful info. As far as I'm concerned, Nifi currently support 3 methods - single-user, LDAP and Kerberos.
Do I really need to use some LDAP to make this happen or there's more simplified solution in that case? If so - can anyone share some ideas what exactly I need to do?
I use Nifi 2.0.0-M2 at the moment. Let me know if some additional info is needed.

Thanks a lot in advance and have a great day!

1 ACCEPTED SOLUTION

avatar
Super Mentor

@AlexisRub 

NiFi has never offered an embedded user authentication management feature until the more recent single-user-provider authentication.  This provider was only introduced in order for Apache NiFi to support HTTPS out-of-the-box default setup.  Over the years since Apache NiFi was open sourced the community noticed unsecured (previous out-of-box default) exposed on the internet, so a decision was made to change the out-of-the-box setup to be secured.  A secured NiFi requires that all users/clients are both authenticated and authorized.  The Single-User-Provider was introduced to simplify access to a secured NiFi for evaluation purposes.  This authentication provider as you have noticed does not support multiple users.   The corresponding single-user-authorizer found in the authorizers.xml configuration also does not support multi-user authorization.  This authorizer simply provides the single-user-provider user complete and full authorized access to everything in the NiFi.  This provider also does not support NiFi clusters.

For a multi-user environment or clustered NiFi a different method of external authentication and authorization must be used.  
Apache NiFi provides support for numerous user/client authentication beyond just single-user, LDAP, and kerberos listed in the User Authentication section of the admin guide. 

Worth noting is that a secured NiFi requires a keytore and truststore and NiFi will generate the keystore and truststore files with self-signed clientAuth/ServerAuth certifcate if the keystore an truststore do not already exist at startup.   

When NiFi is secured (HTTPS enabled and valid keystore and truststore configured) and no additional authentication methods have been configured, user/client authentication is required through the TLS exchange.  This means that when you try to access the NiFi UI via yoru browser NiFi will respond to the browser (client) within the TLS exchange that a clientAuth certificate is "REQUIRED".  If one is not provided the connection is closed.   When additional authenication methods are configured NiFi will instead "WANT" a clientAuth certificate. If the browser does not present a client certificate, NiFi moves on to next configured authentication method.

I wanted to point out the above since certifcates are probably the next easiest way to setup a multi-user authenticated access.  This would require you generating a unique clientAuth certificate for each unique user.  These clientAuth certicates would either be self signed or signed by some certificate authority.  If self signed the public cert for each would need to be added to the NiFi truststore file.  If signed by some authority, only that signing authorities trust chain would need to be added to NiFi's truststore.   The unique users would then load their client certifcate into their browser so it could be presented in the mutual TLS exchange with yoru NiFi.  

In order to authorize multiple users, you would need to stop using the default single-user-authorizer and instead use the StandardManagedAuthorizer. This authorization provider will allow you to define yoru initial admin user (this user will be granted the minimum required admin authorizations.  So initially this would be only user authorized to access the NiFi UI.  Once access, this initial admin user can define additional user and group identities directly from the NiFi UI to which Authorization policies can be defined.  Granting the same policies also granted to your initial admin user will establish a second admin user's authorizations.  More information on the various policies and what they grant can be found here in the Configuring Users & Access Policies section of the admin guide.

That being said, I typically setup OpenLDAP and use the ldap-provider for authentication.  But this requires that you have somewhere to install this (perhaps on same server with NiFi).  The advantage here is you do not need to mess with the NiFi truststore.  You can also use this ldap server for multiple instance of NiFi and NiFi-Registry.

Please help our community thrive. 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

View solution in original post

5 REPLIES 5

avatar
Super Mentor

@AlexisRub 

NiFi has never offered an embedded user authentication management feature until the more recent single-user-provider authentication.  This provider was only introduced in order for Apache NiFi to support HTTPS out-of-the-box default setup.  Over the years since Apache NiFi was open sourced the community noticed unsecured (previous out-of-box default) exposed on the internet, so a decision was made to change the out-of-the-box setup to be secured.  A secured NiFi requires that all users/clients are both authenticated and authorized.  The Single-User-Provider was introduced to simplify access to a secured NiFi for evaluation purposes.  This authentication provider as you have noticed does not support multiple users.   The corresponding single-user-authorizer found in the authorizers.xml configuration also does not support multi-user authorization.  This authorizer simply provides the single-user-provider user complete and full authorized access to everything in the NiFi.  This provider also does not support NiFi clusters.

For a multi-user environment or clustered NiFi a different method of external authentication and authorization must be used.  
Apache NiFi provides support for numerous user/client authentication beyond just single-user, LDAP, and kerberos listed in the User Authentication section of the admin guide. 

Worth noting is that a secured NiFi requires a keytore and truststore and NiFi will generate the keystore and truststore files with self-signed clientAuth/ServerAuth certifcate if the keystore an truststore do not already exist at startup.   

When NiFi is secured (HTTPS enabled and valid keystore and truststore configured) and no additional authentication methods have been configured, user/client authentication is required through the TLS exchange.  This means that when you try to access the NiFi UI via yoru browser NiFi will respond to the browser (client) within the TLS exchange that a clientAuth certificate is "REQUIRED".  If one is not provided the connection is closed.   When additional authenication methods are configured NiFi will instead "WANT" a clientAuth certificate. If the browser does not present a client certificate, NiFi moves on to next configured authentication method.

I wanted to point out the above since certifcates are probably the next easiest way to setup a multi-user authenticated access.  This would require you generating a unique clientAuth certificate for each unique user.  These clientAuth certicates would either be self signed or signed by some certificate authority.  If self signed the public cert for each would need to be added to the NiFi truststore file.  If signed by some authority, only that signing authorities trust chain would need to be added to NiFi's truststore.   The unique users would then load their client certifcate into their browser so it could be presented in the mutual TLS exchange with yoru NiFi.  

In order to authorize multiple users, you would need to stop using the default single-user-authorizer and instead use the StandardManagedAuthorizer. This authorization provider will allow you to define yoru initial admin user (this user will be granted the minimum required admin authorizations.  So initially this would be only user authorized to access the NiFi UI.  Once access, this initial admin user can define additional user and group identities directly from the NiFi UI to which Authorization policies can be defined.  Granting the same policies also granted to your initial admin user will establish a second admin user's authorizations.  More information on the various policies and what they grant can be found here in the Configuring Users & Access Policies section of the admin guide.

That being said, I typically setup OpenLDAP and use the ldap-provider for authentication.  But this requires that you have somewhere to install this (perhaps on same server with NiFi).  The advantage here is you do not need to mess with the NiFi truststore.  You can also use this ldap server for multiple instance of NiFi and NiFi-Registry.

Please help our community thrive. 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

avatar
New Contributor

Thanks a lot for such a detailed answer, @MattWho .
I actually have on-premise AD, but the access to it is kind of complicated.
I'm curious now - will it be easier to try and connect Nifi to this AD or to deploy OpenLDAP on the same server, what do you think?

avatar
Super Mentor

@AlexisRub 

Not sure how to answer that for you.  Typically production users who have access to a corporately managed LDAP/AD would use that with their NiFi.  This provide better security as corporate can mange that adding of new users or removal of users no longer with the organization.   If you also setup the ldap-user-group-provider in NiFi authorizers.xml along with setting of the ldap-provider in the login-identity-providers.xml you'll have a proper production setup.  Let's say a new person joins the company and is added to the AD.  the ldap-user-group-provider (depending on filters) could automatically pull in that new user identity to NiFi allowing your NiFi admin to setup access policies for them easily.  And with the ldap-provider that user could then authenticate to your NiFi (successful authentication does not mean they would have authorized access).  Even better is this opens the ability to use ldap/AD managed groups for authorization.  Let's say you have AD group named nifiadmins. You could sync this group and its members to NiFi via the ldap-user-group-provider and set up local authorization policies using that group identity.   So later some user is added or removed from the AD "nifiadmins" group.  When NiFi syncs with ldap/AD via ldap -user-group-provider (default is every 30 mins), that user would be added or removed as a known member of that group and would gain or lose authorizations without needing any manual action within NiFi to make that happen.   This is most common setup fro production end users with established ldap/AD groups for different teams that will access NiFi.  Different teams can then be authorized access to only specific process groups and actions.

I setup a local ldap which creates a bunch of fake users and groups that i can manage for testing purposes., but not something I would do in a production setup. I would leave the corporate management of user to those responsible for that access control.

Please help our community thrive. 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

avatar
New Contributor

To implement simple authorization in NiFi, configure user authentication, define users/groups, set up access policies, configure login identity providers, and test the setup. This allows for basic user management without LDAP or Kerberos.

avatar
Super Mentor

@gregbowers 

You say "This allows for basic user management without LDAP or Kerberos.", but what method of user authentication are you suggesting to be used for user authentication?

Users and groups that are added via the UI and to which you apply various policies are NOT users that are managed by NiFi for authentication.  Those added user are for setting authorizations policies only.  Authentication must be handed by an authentication provider.  The single-user-provider only support a single user and not multi-users @AlexisRub is looking to support.    So what other provider are you suggesting is configured in the login identity providers?   The only options that can be configured in the login-identity-providers.xml in Apache NiFi are single-user-provider, ldap-provider, and kerberos-provider.    

Are you suggesting some additional third party custom provider?

Thank you,
Matt