Nikhil, LDAP is used for user authentication. Machine-to-machine communications, though, must use certificates, and so authentication in this case is done via certificates. In both cases, though, this is authentication (i.e., identifying who the user is), not authorization (i.e., determining the user's permissions). You'll need to ensure that you assign appropriate permissions for your users. All NiFi nodes will need the Proxy permission, I believe. The Registry User Guide [1] will explain the different permissions/policies available and what they are used for.
Thanks -Mark [1] https://nifi.apache.org/docs/nifi-registry-docs/html/user-guide.html#special-privileges On Sep 17, 2018, at 8:34 AM, Nikhil Chaudhary <[email protected]<mailto:[email protected]>> wrote: Hi Mark, So I added clientAuth and serverAuth both in the certificate and now the error is as follows: NiFi Registry Logs: 2018-09-17 12:26:07,170 INFO [NiFi Registry Web Server-12] o.a.n.r.w.s.NiFiRegistrySecurityConfig Identity in proxy chain not trusted to act as a proxy: org.apache.nifi.registry.web.security.authentication.exception.UntrustedProxyException: Untrusted proxy [CN=*domain.com<http://domain.com/>, O="Company", L=Place, ST= Area, C=TH]. Returning 403 response. NiFi Logs: 2018-09-17 12:26:07,202 INFO [NiFi Web Server-21] o.a.n.w.a.config.NiFiCoreExceptionMapper org.apache.nifi.web.NiFiCoreException: Unable to obtain listing of buckets: org.apache.nifi.registry.client.NiFiRegistryException: Error retrieving all buckets: Untrusted proxy [CN=*domain.com<http://domain.com/>, O="Company", L= Place, ST=Area, C=TH]. Contact the system administrator.. Returning Conflict response. 2018-09-17 12:26:07,203 DEBUG [NiFi Web Server-21] o.a.n.w.a.config.NiFiCoreExceptionMapper org.apache.nifi.web.NiFiCoreException: Unable to obtain listing of buckets: org.apache.nifi.registry.client.NiFiRegistryException: Error retrieving all buckets: Untrusted proxy [CN=*domain.com<http://domain.com/>, O="Company", L= Place, ST= Area, C=TH]. Contact the system administrator. Both the registry and NiFi are running on the same instance for test purposes and have the same host set up in the configuration: nifi.domain.com<http://nifi.domain.com/> Any idea what could be wrong now? The only information I've found online is to add the Node information within the authorizers file, however since we use LDAP, I believe that isn't necessary? Or is it similar to the set up of nifi-to-nifi clustering? Cheers, Nikhil C. On Thu, Sep 13, 2018 at 8:40 PM Mark Payne <[email protected]<mailto:[email protected]>> wrote: Hi Nikhil, The property that you mention: "nifi.registry.security.needClientAuth" applies only to user logins. This allows users to login via certificate or other methods by not requiring that they present a client certificate. However, NiFi & registry require mutual authentication for all machine-to-machine interactions. So in order to have NiFi talk to the registry, NiFi's cert will need to have client auth usage as well. Thanks -Mark On Sep 13, 2018, at 5:35 AM, Nikhil Chaudhary <[email protected]<mailto:[email protected]>> wrote: Hey Guys, Been stumped with a certificate issue. A bit of info on the deployment strategy. NiFi is running with a wildcard certificate in its keystore (*.domain.com<http://domain.com/>) – It’s a self signed certificate. We’ve added the Root CA in the truststore of NiFi. We’ve used the same keystore to run NiFi registry. So installing the Root CA on my laptop, I can access NiFi on HTTPS with no errors or warnings. In theory the Root CA within the NiFi truststore should do the same when accessing NiFi registry, shouldn’t it? I enabled debug logs and the error that came up was: Caused by: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication The certificate only has serverAuth in it’s extended key usage but shouldn’t that be enough? I’ve seen emails and posts online regarding NiFi clustering in which case clientAuth needs to be enabled but this case seems different? ClientAuth in NiFi registry properties file is set as false. nifi.registry.security.needClientAuth=false Is there something I’m missing or not doing correctly? Stack Trace: 2018-09-12 11:02:22,581 DEBUG [NiFi Registry Web Server-15] org.eclipse.jetty.server.HttpConnection javax.net.ssl.SSLHandshakeException: General SSLEngine problem at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529) ~[na:1.8.0_181] at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) ~[na:1.8.0_181] at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) ~[na:1.8.0_181] at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) ~[na:1.8.0_181] at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[na:1.8.0_181] at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:621) ~[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:322) [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:231) [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:258) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:147) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:122) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:201) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:133) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.8.0_181] at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) ~[na:1.8.0_181] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) ~[na:1.8.0_181] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) ~[na:1.8.0_181] at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1979) ~[na:1.8.0_181] at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:237) ~[na:1.8.0_181] at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) ~[na:1.8.0_181] at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) ~[na:1.8.0_181] at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) ~[na:1.8.0_181] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_181] at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) ~[na:1.8.0_181] at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:727) ~[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] ... 15 common frames omitted Caused by: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication at sun.security.validator.EndEntityChecker.checkTLSClient(EndEntityChecker.java:238) ~[na:1.8.0_181] at sun.security.validator.EndEntityChecker.check(EndEntityChecker.java:145) ~[na:1.8.0_181] at sun.security.validator.Validator.validate(Validator.java:274) ~[na:1.8.0_181] at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[na:1.8.0_181] at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:279) ~[na:1.8.0_181] at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:130) ~[na:1.8.0_181] at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1966) ~[na:1.8.0_181] ... 22 common frames omitted Thank You. Best Regards, Nikhil C.
