NiFi and SSL for authorization

Introduction

By default, your NiFi installation is not protected at all. Anyone knowing the hostname of your NiFi hosts can connect to them with a simple web browser.
To protect access to NiFi, by adding user authentication and authorization, you will need to enable SSL. Client-side certificates, generated by the NiFi CA are going to be used not only to setup an encrypted link to the NiFi hosts but also to provide user authentication.
When SSL has been enabled for NiFi, it is no more possible to connect using HTTP.
 

In the Ambari GUI

If you want to enable SSL with a NiFi CA installed, and are not yet using Ranger to manage authorization:
  1. Check the Enable SSL? box.
  2. Specify the NiFi CA Token
  3. Verify that the authorizations.xml file on each node does not contain policies. The authorizations.xml is located in {nifi_internal_dir}/conf. By default, this location is /var/lib/nifi/conf/, and the value of {nifi_internal_dir} is specified in the NiFi internal dir field under Advanced nifi-ambari-config.
If authorizations.xml does contain policies, you must delete it from each node. If you do not, your initial Admin Identity and Node Identities changes do not take effect.
Unless you’ve done some previous tries with NiFi authorization before, this file doesn’t contain any policies. Anyway, if you are (re)doing the configuration of SSL, it is a good idea to delete this file and the users.xml in the same directory before restarting the NiFi services after changing their configuration in Ambari.
Remark: these files (authorizations.xml and users.xml) are automatically generated when restarting the NiFi services. So they will be present when NiFi is running. But by deleting them, you are forcing the system to loose previous configuration settings that would negatively interfere with the new ones.
  1. Specify the Initial Admin Identity. The Initial Admin Identity is the identity of an initial administrator and is granted access to the UI and has the ability to create additional users, groups, and policies. This is a required value when you are not using the Ranger plugin for NiFi for authorization.
The Initial Admin Identity format is CN=<name>, OU=NIFI.
After you have added the Initial Admin Identity, you must immediately generate certificate for this user.
Remark: in NiFi, DN’s are case- and blank-sensitive. Apparently the software is doing a strict match on the DN strings it receives with the one in the configuration. So respect everywhere the case of the value as well the one of the elements (CN, OU, O, …) and the number of spaces between elements, punctuation, etc. By default, there is a space between the comma and the OU.
  1. Specify the Node Identities. This indicates the identity of each node in a NiFi cluster and allows clustered nodes to communicate. This is a required value when you are not using the Ranger plugin for NiFi for authorization.
<property name="Node Identity 1">CN=node1.fqdn, OU=NIFI</property>
<property name="Node Identity 2">CN=node2.fqdn, OU=NIFI</property>
<property name="Node Identity 3">CN=node3.fqdn, OU=NIFI</property>
Replace node1.fqdn, node2.fqdn, and node3.fqdn with their respective fully qualified domain names.
  1. Once the configuration is saved, you have to restart the services.
Note that the files deleted above (authorizations.xml and users.xml) are recreated at service startup, but then, they should be recreated with the correct settings, losing any potential errors you may have introduced in previous tries. Because when the file already exists, it is not recreated but new parameters are appended, not overwritten.
 

Creating the web browser identity

With the help of the NiFi TLS toolkit, you will be able to generate the certificates and private keys (bundled into a PKCS#12 file) for your clients that need connection to the NiFi GUI.
On one host where NiFi service has been installed, you’ll do:
cd /var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/files/nifi-toolkit-1.2.0.3.0.0.0-453/
export JAVA_HOME=/usr/jdk64/jdk1.8.0_112
bin/tls-toolkit.sh client -c <nifi host FQDN> -D "CN=<name>, OU=nifi" -t <CA Token> -p 10443 -T PKCS12
  • “CA Token” is the secret CA Token defined in the Ambari configuration
  • “Name” can be what you want, but the resulting DN must match the “Initial Admin” configured with Ambari. Remember to type the DN exactly like you did in the NiFi configuration (Initial Admin parameter value) – same case, same number of blanks.
In case of bad « CA Token », you will see an error like that :
Service client error: Received response code 403 with payload {"hmac":null,"pemEncodedCertificate":null,"error":"forbidden"}
If you prefer, you can install the TLS toolkit on the computer from which you will launch the web browser. You can get the TLS toolkit from the Amabari server by downloading it from the following URL:http://<your ambari server>/resources/common-services/NIFI/1.0.0/package/archive.zip
Unzip archive.zip and descent to the directory files\nifi-toolkit-1.2.0.3.0.0.0-453 where you will run the same command as above. (on Windows, use a Command prompt and run the same script with the .bat extension).
 
This will create 4 files in the directory where the command is run: config.json, keystore.pkcs12, nifi-cert.pem and truststore.jks.
Import keystore.pkcs12 into your Web Browser certificates. For that, transfer the file to your PC, rename it with a .p12 extension and double-click it.
The password for the importation is the value of the parameter "keyStorePassword" in the config.json file.

Connect to the URL of the SSL protected Web GUI of NiFi.
If the certificate and private key contained into the PKCS12 file are correctly installed, you will be prompted to select a certificate identity by your browser. Select the one matching the NiFi server (look at the displayed DN) you want to connect to.

If you are not able to login and receive an error from NiFi:
  • About the user DN not recognized: checked the “Initial Admin” parameter in the configuration and the DN name in the certificate, especially the case and the spaces.
  • About the host not recognized as a valid proxy, check that the DN of the NiFi nodes in the “Nodes Identities” is well written with the same case and number of blanks used when defining DN elements.