NiFi, Authentication and Authorization15 Nov 2016 | NiFi
Today, I’d like to write about NiFi auth. Auth is an ambiguous word, specifically, Authentication (AuthN) and Authorization (AuthZ). AuthN is a process to identify who they are. AuthZ is a process to allow what they can. So, AuthN should always happen before AuthZ. Let’s see how NiFi handles AuthN and AuthZ!
Most of readers probably knows, but NiFi’s AuthZ and AuthN are only enabled when you secure your NiFi installation (HTTPS).
In NiFi, the primary method to identify who made the request is Client Certificate. When a secured NiFi receives a request, it first checks whether a client certificate is provided. If so, it checks if the certificate is trustworthy. Then extracts Distinguished Name (DN) to use it as NiFi user identifier.
When a request doesn’t contain a client certificate, NiFi lets a LoginIdentityProvider to identify the user. Currently, NiFi supports two LoginIdentityProvider implementation, those are LdapProvider and KerberosProvider.
Once NiFi successfully identifies a user submitted the request, it authorize whether the user can perform that request. Note that at this point, the mechanism used to identify the user becomes irrelevant to AuthZ the request.
NiFi has a way to do this out of the box, it provides a way to define Policies to allow users/groups performing certain actions on specific resources. You can use NiFi Web UI to configure those policies. (Access Policy Configuration Examples)
If you’d like to authorize the requests more centalized way, like control AuthZ among other Hadoop eco-system such as HDFS or Kafka, then RangerNiFiAuthorizer would be the way to go. (Here is a great post by Bryan Bende, Using the Apache Ranger Authorizer)
Different occasions NiFi authn/authz requests
Let’s look at some scenarios in which a client and NiFi perform auth processes.
- An user has installed his/her client certificate into a web browser (or OS keychain). When they access NiFi Web UI, the certificate is used. NiFi extract DN from the certificate, and AuthN the request with the DN. Then AuthZ the request.
- An user accesses NiFi Web UI. However, he/she doesn’t have a client certificate configured. NiFi respond with a login screen, the user input their username and password. NiFi AuthN the request, using an imprementation of LoginIdentityProvider (LDAP or Kerberos). After the request is AuthNed, then NiFi AuthZ the request.
- (And 4) Regardless of whether a Site-to-Site NiFi is secured, there’s only one way to AuthN Site-to-Site client, that is client certificate. Other login credentials can not be used with Site-to-Site. A client NiFi uses its certificate configured in a key store, which is defined in nifi.properties.
- NiFi also authenticate other NiFi instances when clustering protocol is secured. Client certificates are used to do so.
How to use LDAP to AuthN requests?
I used an OpenLDAP docker container. To start a LDAP server, execute command below:
Then LDAP server is accessible using docker machine ip.
Next, you need to configure
login-identity-providers.xml needs to be configured like below:
Then, restart NiFi. Please also refer NiFi docs.
How to display a NiFi login window?
To be honest, this was the most difficult step for me to figure out.. If I specify a client cert, then NiFi won’t respond with a login screen..
In order to Not Select a certificate is just simply click Cancel button!
Then you can see the Log In window. The docker container has an
admin user configured.
admin as User, and
admin as Password to login NiFI.
AuthZ by DN or mapped UserId
Finally, I’d like to mention about policy setting and DN mapping feature.
After NiFi AuthN an user request, it uses DN as user identifier e.g. cn=admin,dc=example,dc=org, even if I typed and logged in with
So, the DN
cn=admin,dc=example,dc=org should be configured properly in NiFi policy settings to view the UI.
However, DN looks complicated, doesn’t it? You may want to make it looks simpler.
Or if multiple AuthN mechanisms are used but you’d like to consolidate how an user identifier looks like (e.g. admin), then DN mapping feature might be handy.
You can find following example entries in
By using these mapping definitions, AuthZ policies can be managed easier.