Anonymous user in secure setup

[#1]

1. Setup Nifi 1.11.4 secure using my own certs and kerberos authentication accepting username/password.  All is working fine can log in using kerberos username/password as initial admin user.

2. Setup Nifi Registry 0.6.0 using same certs and kerberos all is fine. Again all is working fine can log in using kerberos username/password as initial admin user.

Problem is that when adding registry to secure Nifi it seems they attempt to talk using the username 'anonymous'.

If I add the user "anonymous" to Registry giving it permissions to proxy, then all works fine, however registry shows all changes were performed by 'anonymous' 
Also can't use policies to not allow the anonymous user access to the UI 

I can't find any documentation on why I would need to create a user with name 'anonymous'
In fact most documentation says when using https that anonymous access it not supported.

Q. How does Nifi/Registry identify the identity of the host in standalone mode? If I generate certs with tls-toolkit.sh it all works fine - but uses the identity I put in the cert. So I assume the problem is with getting this identity from my cert - but I don't see any errors just the name 'anonymous'?

Any help appreciated

Thanks

John

[#2 · Accepted solution]

@JohnA 

The latest versions of NiFi-Registry introduced public buckets.  When accessing the NiFi-Registry's https URL without presenting either a client certificate or responding to a spnego auth challenge (provide spnego properties are configured), the user will access to the public buckets as the anonymous user.  If there are no anonymous buckets the user will simply see the NiFi-Registry Ui with nothing displayed they can use.  To access the non public buckets and any other capability requiring authorization, the user/client would need to authenticate.  In the case where a login provider is setup, the login option will be available in upper right corner which a user can click on to "login".

When it comes to NiFi interacting with NiFi-Registry a successful mutual TLS handshake must be successful; otherwise, the connection will happen as anonymous since no user authentication occurred.  You should not be authorizing the anonymous user, but instead fixing the mutual TLS handshake between your NiFi and NIFi-Registry.  The keystore and truststore configured in both the nifi.properties and nifi-registry.properties files are what are used in facilitating that successful handshake.  Since NiFi is acting as the client in this handshake, its PrivateKeyEntry in its keystore must support clientAuth EKU and its truststore must be contain the complete trust chain for the server certificate being present by NiFi-Registry.  The truststore used in NiFi-Registry must contain the complete trust chain for the certificate being presented by the client (NiFi).  The NiFi certificate authenticated string must then be authorized to read ll buckets and proxy within NiFi-Registry.  Additionally any user initiating version control actions from within NiFi must also be authorized within NiFi-Registry for any buckets they will need access to.

Hope this helps,

Matt

[#3]

Yes this really helped as the problem was a misconfiguration. The truststore and keystore in Nifi Registry were both pointing to the truststore.

On correcting this all is working fine.

Thanks

John