SSLHandshakeException Nifi and Nifi Registry

[#1]

My secured nifi instance is able to communicate with my secured nifi-registry instance but it fails to recognize the user for version control

I keep getting this error

Unable to obtain listing of buckets: javax.net.ssl.SSLHandshakeException: No name matching <hostname> found

 I have added `CN=<hostname>, ....` as user to nifi-registry yet I keep getting the above error.

[#2]

@sambeth 

Your NiFi instance is proxying the request for your NiFi user to NiFi-Registry when you try to start version control, change version, etc on a process group on the NiFi canvas.

All your NiFi hosts must be authorized for the following in NiFi-Registry:

You can authorize these Special Privileges from teh NiFi-Registry UI by clicking on the wrench icon in upper right corner and clicking the pencil (edit) icon to the right of your NiFi host in the list of users.

This allows your NiFi hosts to read all the buckets, but your NiFi user who the request is being proxied for must still be authorized for whichever specific buckets you want that user to have access to.

Typically an admin user will be responsible for creating buckets in NiFi-Registry and the authorizing specific user access to those buckets.  Again through the wrench icon, the admin would create that new bucket and then click on the pencil (edit) icon which shows the following:

 Above is example for a bucket "user-bucket" I created using the NiFi-Registry Admin user.
I then authorized my users group and nifisme1 user ability to read (can import flows from bucket and see flows in bucket), write (can version control new PG to this bucket and commit new version of existing version controlled PG), and delete (can deleted version controlled flows from bucket via NiFi-Registry UI).

If you found this solution helped resolve your issue, please take a moment to login and accept it.

Hope this helps,

Matt

[#3]

I have resolved this issue. The problem was I had to put this OU=NIFI as
part of my dns for the user. I thought OU could be anything but it turns
out Nifi wanted that specifically.

[#4]

@sambeth 

NiFi authorization lookups require an exact case sensitive match between the resulting authentication user string or associated group string (NIFi user group providers configured in the authorizers.xml are responsible for determining associations between user strings and group strings within NiFi) and the user/group strings which the the authorized policies are assigned to.

So if the User identity string that results after Authentication process is:
"CN=John, OU=Doe", then that exact case sensitive string must be what the policies are authorized against.

NiFi does provide the ability to use Java regular expressions post authentication to manipulate the authentication string before it is passed on for authorization.  These Identity mapping pattern, value, and transform properties can be added to the nifi.properties file.
https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#identity-mapping-properties
For example:

nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?)$
nifi.security.identity.mapping.value.dn=$1
nifi.security.identity.mapping.transform=LOWER

Now if Authentication resulted in string "CN=John, OU=Doe", the above Regex would match and the resulting user client string would be "john" (capture group 1 is value used and transformed to all lowercase)

You can create as many of these mapping pattern sets of properties as you like as long as each property name is unique in its last field...

nifi.security.identity.mapping.pattern.dn2=
nifi.security.identity.mapping.pattern.kerb=
nifi.security.identity.mapping.pattern.kerb2=
nifi.security.identity.mapping.pattern.username=
etc....

IMPORTANT note:  These "patterns" are evaluate against every authenticated string (this includes Mutual TLS authentication such as those between NIFi nodes using the NiFi keystore) in alpha-numeric order.  The first java regular expression to match will have its value applied and transformed.  So making sure you properties are build in order of most complex regex to most generic regex is very important.

Hope this helps you,

Matt