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).

AuthN

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.

AuthZ

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.

1. 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.
2. 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.
3. (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.
4. NiFi also authenticate other NiFi instances when clustering protocol is secured. Client certificates are used to do so.

Icons are provided by: Icon pack by Icons8 and simpleicon

How to use LDAP to AuthN requests?

I used an OpenLDAP docker container. To start a LDAP server, execute command below:

docker run --name my-openldap -p 389:389 -p 636:636 -d osixia/openldap

Then LDAP server is accessible using docker machine ip. Next, you need to configure nifi.properties:

nifi.security.user.login.identity.provider=ldap-provider

Also, login-identity-providers.xml needs to be configured like below:

  <provider>
    <identifier>ldap-provider</identifier>
    <class>org.apache.nifi.ldap.LdapProvider</class>
    <property name="Authentication Strategy">SIMPLE</property>
    <property name="Manager DN">cn=admin,dc=example,dc=org</property>
    <property name="Manager Password">admin</property>
    <property name="Connect Timeout">10 secs</property>
    <property name="Read Timeout">10 secs</property>
    <property name="Url">ldap://192.168.99.100</property>
    <property name="User Search Base">dc=example,dc=org</property>
    <property name="User Search Filter">cn={0}</property>
    <property name="Authentication Expiration">12 hours</property>
  </provider>

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. I used 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 admin. 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 nifi.properties:

# Identity Mapping Properties #

# These properties allow normalizing user identities such that identities coming from different identi ty providers

# (certificates, LDAP, Kerberos) can be treated the same internally in NiFi. The following example dem onstrates normalizing

# DNs from certificates and principals from Kerberos into a common identity string:

#

# nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), L=(.*?), ST=(.*?), C=(.*?)$

# nifi.security.identity.mapping.value.dn=$1@$2

By using these mapping definitions, AuthZ policies can be managed easier.