Created on 10-06-2024 05:57 PM - edited 10-06-2024 06:15 PM
hello.
I am a beginner in NIFI.
Currently, there are two CENTOS7-based Linux servers with NIFI version 1.27.0 installed.
Clustering two servers
It is linked with external zookeepers.
The nifi setup was completed with the ssl authentication setup using the jks file.
In this state, I changed the "nifi.security.user.authorizer" option to "managed-authorizer".
At this time, I would like to create and use multiple users in the users.xml file without LDAP, Kerberos, etc(only users.xml file and authorizations.xml file).
Example user.xml file and authorizations.xml
I'm curious about the file example.
Also if possible
I would like to see again how to configure these settings.
After searching, I found that there is no way to dynamically add users without restarting the service.
So ultimately what I want to do is
Without LDAP or Kerberos,
After creating multiple users in users.xml and restarting the service,
I want to log in with those accounts.
Created 10-07-2024 06:12 AM
@newbeede
The only Authentication provider provided with NiFi that supports a single managed user with password is the Single User provider. Apache NiFi create this authentication provider so that NiFi out-of-the-box could run securely over HTTPS. It is intended for non clustered use to make it easy to evaluate the product.
The users.xml is created by the file-user-group-provider inside the authorizers.xml. It's is for authorization use only and has nothing to do with user/client authentication. In order to setup various authorization policies through the file-access-policy provider (also found in the authorizers,.xml and generates an authorizations.xml file), the authorizer must be aware of the user/client identities for which policies will be granted. The file-user-group-provider is just one of the available providers that creates these user identities within NiFi for the sole purpose of policy assignment.
The file-user-group-provider is used to generate the Initial Admin Identity and the Identities for each of your cluster nodes. The users.xml file it creates will only initially contain those identities. The file-user-group-provider will ONLY generate the users.xml on NiFi startup if it does NOT already exist. Once the NiFi UI is accessed by the initial admin identity, additional user identities and policies are setup from within the UI. Additional user identities and group identities added through the NiFi UI will be added to the users.xml.
If you are using the Single-User authentication provider and single-user authorizer, then users and polices will not present in the UI when accessed.
The File-access-policy provider sets up admin polices for the defined initial admin identity and sets up initial node required policies. The policies are needed for that initial admin to be authorized to create additional user identities and configure additional policy authorizations from with the NiFi UI. The file-access-policy provider will ONLY generate the authorizations.xml file on NiFi startup if it does NOT already exist. Additional policies setup from with the NiFi UI are added to the authorizations.xml file.
So to be clear, NiFi does allow you to dynamically add/remove additional user identities and dynamically add/modify/remove authorizations from the NiFi UI without needing a restart.
When it comes to handling user authentication, a secured NiFi will always support client Authentication as first authentication method attempted. This is the only method used for the NiFi nodes to communicate with one another. When additional authentication method are configured, NiFi will still WANT a client auth certificate in the TLS exchange; however if one is not provided, NiFi will try the next authentication method configured.
The most commonly used additional authentication method used are the LDAP-provider and Kerberos-provider.
The LDAP-provider allows you to authenticate via your own LDAP/AD.
Sample:
<provider>
<identifier>ldap-provider</identifier>
<class>org.apache.nifi.ldap.LdapProvider</class>
<property name="Authentication Strategy">SIMPLE</property>
<property name="Manager DN"></property> <-- MUST be configured
<property name="Manager Password"></property> <-- MUST be configured
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url">ldap://<hostname>:<port></property> <-- MUST be configured
<property name="User Search Base">CN=Users,DC=example,DC=com)</property> <-- MUST be configured
<property name="User Search Filter">cn={0}</property> <-- MUST be configured
<property name="Identity Strategy">USE_USERNAME</property> <-- MUST be configured
<property name="Authentication Expiration">12 hours</property>
</provider>
USE_USERNAME: Upon successful LDAP/AD authentication, the user identity string as typed (case sensitive) in the username login window will be passed to the authorizer to look up policies assigned to the user identity.
USE_DN: Will pass the DN returned from LDAP/AD after successful authentication to the authorizer as the user identity for policy assignment lookup.
Kerberos-provider allows you to authentication using your kerberos principal and password. Sample:
<provider>
<identifier>kerberos-provider</identifier>
<class>org.apache.nifi.kerberos.KerberosProvider</class>
<property name="Default Realm">NIFI.APACHE.ORG</property>
<property name="Authentication Expiration">12 hours</property>
</provider>
Bottom line is Apache NiFi does not support managing multiple local accounts. In fact the single-user provider is actually fairly new to Apache NiFi. Prior to its existence, NiFi out-of-the-box started up un-secure over http. Since most browser now force http to https, Apache NiFi added this provider to make it easy for first time user to evaluate the service.
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
Created 10-07-2024 06:12 AM
@newbeede
The only Authentication provider provided with NiFi that supports a single managed user with password is the Single User provider. Apache NiFi create this authentication provider so that NiFi out-of-the-box could run securely over HTTPS. It is intended for non clustered use to make it easy to evaluate the product.
The users.xml is created by the file-user-group-provider inside the authorizers.xml. It's is for authorization use only and has nothing to do with user/client authentication. In order to setup various authorization policies through the file-access-policy provider (also found in the authorizers,.xml and generates an authorizations.xml file), the authorizer must be aware of the user/client identities for which policies will be granted. The file-user-group-provider is just one of the available providers that creates these user identities within NiFi for the sole purpose of policy assignment.
The file-user-group-provider is used to generate the Initial Admin Identity and the Identities for each of your cluster nodes. The users.xml file it creates will only initially contain those identities. The file-user-group-provider will ONLY generate the users.xml on NiFi startup if it does NOT already exist. Once the NiFi UI is accessed by the initial admin identity, additional user identities and policies are setup from within the UI. Additional user identities and group identities added through the NiFi UI will be added to the users.xml.
If you are using the Single-User authentication provider and single-user authorizer, then users and polices will not present in the UI when accessed.
The File-access-policy provider sets up admin polices for the defined initial admin identity and sets up initial node required policies. The policies are needed for that initial admin to be authorized to create additional user identities and configure additional policy authorizations from with the NiFi UI. The file-access-policy provider will ONLY generate the authorizations.xml file on NiFi startup if it does NOT already exist. Additional policies setup from with the NiFi UI are added to the authorizations.xml file.
So to be clear, NiFi does allow you to dynamically add/remove additional user identities and dynamically add/modify/remove authorizations from the NiFi UI without needing a restart.
When it comes to handling user authentication, a secured NiFi will always support client Authentication as first authentication method attempted. This is the only method used for the NiFi nodes to communicate with one another. When additional authentication method are configured, NiFi will still WANT a client auth certificate in the TLS exchange; however if one is not provided, NiFi will try the next authentication method configured.
The most commonly used additional authentication method used are the LDAP-provider and Kerberos-provider.
The LDAP-provider allows you to authenticate via your own LDAP/AD.
Sample:
<provider>
<identifier>ldap-provider</identifier>
<class>org.apache.nifi.ldap.LdapProvider</class>
<property name="Authentication Strategy">SIMPLE</property>
<property name="Manager DN"></property> <-- MUST be configured
<property name="Manager Password"></property> <-- MUST be configured
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url">ldap://<hostname>:<port></property> <-- MUST be configured
<property name="User Search Base">CN=Users,DC=example,DC=com)</property> <-- MUST be configured
<property name="User Search Filter">cn={0}</property> <-- MUST be configured
<property name="Identity Strategy">USE_USERNAME</property> <-- MUST be configured
<property name="Authentication Expiration">12 hours</property>
</provider>
USE_USERNAME: Upon successful LDAP/AD authentication, the user identity string as typed (case sensitive) in the username login window will be passed to the authorizer to look up policies assigned to the user identity.
USE_DN: Will pass the DN returned from LDAP/AD after successful authentication to the authorizer as the user identity for policy assignment lookup.
Kerberos-provider allows you to authentication using your kerberos principal and password. Sample:
<provider>
<identifier>kerberos-provider</identifier>
<class>org.apache.nifi.kerberos.KerberosProvider</class>
<property name="Default Realm">NIFI.APACHE.ORG</property>
<property name="Authentication Expiration">12 hours</property>
</provider>
Bottom line is Apache NiFi does not support managing multiple local accounts. In fact the single-user provider is actually fairly new to Apache NiFi. Prior to its existence, NiFi out-of-the-box started up un-secure over http. Since most browser now force http to https, Apache NiFi added this provider to make it easy for first time user to evaluate the service.
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