@pnac03  When "nifi.registry.security.needClientAuth" is set to "true", NiFi-Registry will "Require" a clientAuth certificate be presented in every mutualTLS exchange with the NiFi https endpoint.    When set to "false", NiFi-Registry will "Want"' a clientAuth certificate to be provided in every  mutualTLS exchange.  When you access NiFi-Registry's URL you'll notice that your browser does not present a ClientAuth certificate so NIFi-Registry shows anonymous access.   You then must click login to provide your ldap credentials to authenticate as your user for which you have setup authorization for.  All connections between NiFi and NiFi-Registry must present a clientAuth certificate in response to the Want since no other auth method is supported in that connection pathway.   Securing your NiFi or NiFi-Registry requires providing proper tls certificate keystore and truststore.  Setting up LDAP as an alternative method of authentication is not a requirement; however, it is the most commonly method used.  You could just create a clientAuth certificate (must be signed by a trusted authority in the truststore) for every user that can be loaded into their browser to authenticate access to NiFi and NiFi-Registry.  Authorization happens after successful authentication.  The user/client identity resulting from successful authentication is based to the configured authorizer to verify that client/user identity is authorized as needed for the request endpoint.  So authorizers is always going to be needed.  Which user-group-providers you choose to use in the authorizers.xml to define the client/user identities you will set authorization policies for is up to you.  The file-user-group-provider is needed to setup authorizations for your clientAuth certificate based identities.   Of course you can also use this provider to manually configure your user identities that match with your ldap (simple if you only have few users).  the ldap-user-group-provider is better if you want to do ldap group based authorizations or you want to authorize a lot of user identities.  Doing a based on ldap groups makes it easy to control access by adding or removing users from groups in ldap.  Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@pnac03  Looks like you truncated the output of the keytool command for your keystore. What are the "ExtendedKeyUsages" (EKU) on your PrivateKeyEntry? It must have:   ExtendedKeyUsages [ serverAuth clientAuth ]   If it is missing "clientAuth", it can't be used in NiFi by the NiFRegistryFlowRegistryClient because it won't present a client certificate in the mutualTLS exchange.  But even above if no clientAuth EKU would not explain the exception you get: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target This exception is caused by a trust issue.  The copied over keystore and truststore are owned by the NiFi service user and the NiFi service user can traverse the directory path the the keystore and truststore?  The URL used in the NiFiRegistryFlowRegistryClient is using https and not http? Thanks, Matt ... View more

@Rohit1997jio  Yes it can be fast, but that depends on your dataflow(s). How many other dataflows is your NiFi also running?  All these dataflows share the same JVM resources and utilize server resources.   Also concurrency is important so having a match between number of partitions in your source Topic A and the concurrency within your ConsumeKafkaRecord processor is important.  Concurrent tasks in the ConsumeKafkaRecord you be set using the following formula: (num partitions in Topic A) / (num NiFi nodes in cluster) = (num concurrent tasks set on ConsumeKafkaRecord) Example: Kafka Topic partions = 12 partitions NiFI cluster num nodes = 3 Concurrent tasks set on ConsumeKafkaRecord = 4 4 X 3 = 12 consumers in the consumer group (1  consumer per partition in source topic) Also in NiFI keep in mind that each concurrent task utilizes a thread from NiFi's "Max Timer Driven Thread Count" thread pool. The default pool size is 10.   This means that only 10 concurrent task can execute at the same time.  Generally speaking threads milliseconds, but for optimal performance you'll want to mange your server CPU load average resources and set the pool higher to maximize your throughput performance.   NiFi can show you the Core Load Average (1 = 100% utilization of one physical core).    So if your NiFi server has 4 cores and the load average is 4 or higher, the CPU is saturated.  You'll be able to use this Core Load Average data to determine how much your can increase the size of the "Max timer Driven Thread Count" pool setting.   NiFi recommends setting your "Max Timer Driven Count" initially to 2 - 4 times the number of Physical cores on the NiFi node.  This assume all nodes in the NiFi cluster have same number of physical cores.   If nodes have various numbers of physical cores, use the nodes with the fewest to set your initial pool size.  Then monitor core load average across all NiFi nodes and adjust accordingly.  There is no way to configure different thread pools per node in a NiFi cluster, NiFi expects all all servers in a NiFi cluster to have same hardware configuration.   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more