About MattWho

VVPeter · ‎08-07-2025

Hi Matt, Just to clarify one point—specifically in the context of NiFi REST API 2.0+—is there an endpoint where we can exchange an Azure AD access token for a NiFi access token, similar to a token exchange flow? Or, if such a direct token exchange is not supported (i.e., the token must always be obtained via browser redirection to the NiFi URL), could you please confirm that this is indeed the case? Thanks in advance!

JohnCarter · ‎08-03-2025

So I stumbled on this tool called Data Flow Manager (DFM) while working on some NiFi stuff, and… I’m kinda blown away? Been using NiFi for a few years. Love it or hate it, you know how it goes. Building flows, setting up controller services, versioning… it adds up. Honestly, never thought I’d see a way around all that. With DFM, I literally just picked the source, target, and a bit of logic. No canvas. No templates. No groovy scripting. Hit deploy, and the flow was live in under a minute.

MattWho · ‎08-01-2025

@Krish98 When you secure NiFi (HTTPS enabled), in the TLS exchange NiFi will either REQUIRE (if no additional methods of authentication are configured) or WANT (when additional method of authentication are configured, like SAML) a clientAuth certificate. This is necessary for NiFi clusters to work. Even when one node communicates with another, the nodes to be authenticated (done via a mutual TLS exchange) and authorized (authorizing those clientAuth certificates to necessary NiFi policies). When accessing the NiFi UI, a MutualTLS exchange happens with your browser (client). If the browser does not respond with a clientAuth certificate, NiFi will attempt next configured auth method, it your case that would be SAML. MutualTLS with trusted ClientAuth certificates removes the need to obtain any tokens, renew tokens, and simplifies automation tasks with the rest-api whether interacting via NiFi built dataflows or via external interactions with the NiFi rest-api. The ClientAuth certificate DN is what is used as the user identity (final user identity that needs to be authorized is derived from the DN post any Identity Mapping Properties manipulation). Just like your SAML user identities, your clientAuth certificate derived user identity needs to be authorized to whichever NiFi policies are needed for the requested rest-api endpoint. Tailing the nifi-user.log while making your rest-api calls will show you the derived user identity and missing policy when request is not authorized. 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

asand3r · ‎07-31-2025

OK, @MattWho, thanks for your help.

PradNiFi1236 · ‎07-30-2025

thanks @MattWho for replying we were able to sort it out after we enabled sticky sessions on load balancer target group attributes.

MattWho · ‎07-30-2025

@justloseit NiFi Process groups are just logical containers for processors. A Process group does not run/execute. Selecting "Start" on a process group triggers starting of all the components within that process group. In your case it sounds like you have have setup cron scheduling on your ingest/starting processor(s) within the process group. All downstream processors to that source should be set run all the time and not cron based scheduling. So what you are really looking for is how long it took the processors within that process group to process all produced FlowFiles to point of termination? Besides looking at the lineage data for each FlowFile that traverses all the processor in a process group, I can't think of how else you would get that data. Take a look at the SiteToSiteProvenanceReportingTask available in Apache NiFi. It allows you send the provenance data (produces a lot of data depending on size of yoru dataflows and amount of FlowFiles being processed) via NiFi's Site-To-Site protocol to another NiFi instance (would recommend a separate dedicated NiFi to receive this data). You can then build a dataflow to process that data how you want to retain what information you need, or send it to an external storage/processing system. 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

DianaTorres · ‎07-24-2025

@Siva227 Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.

asand3r · ‎07-24-2025

Thank you, @MattWho. It's a bit clear for me now.

dimi_yu · ‎07-22-2025

The error ERR_BAD_SSL_CLIENT_AUTH_CERT is a security-related bug that appears in web browsers, especially Google Chrome, due to a failure to interact with the SSL/TLS client authentication process. This issue arises when SSL/TLS certificates are required on both client and server sides, but the client fails to present a valid certificate or the server can't verify it. Common causes include certificate misconfiguration, incorrect device date/time, software issues, or interference from browser extensions and antivirus programs. There are many different ways to fix the error which you need to understand properly in detail. Furthermore I found the helpful resource at:- https://cheapsslweb.com/resources/how-to-fix-the-err_bad_ssl_client_auth_cert-error. I hope it helps!

MattWho · ‎07-15-2025

Preferred to have new question for unique questions, but.... Keep in mind these things when it comes to user identities and authorizations: 1. user identities are case sensitive in NiFi. So the user identity from oidc must match exactly the initial admin user identity you passed to the file-user-group-provider and the file-access-policy-provider. 2. The file-user-group-provider will only generate the users.xml file if it does NOT already exist. So if you edit the configuration of the file-user-group-provide after the users.xml already exists, those change will not be made to that existing users.xml file. (remove it and restart so it gets created again) 3. The file-access-policy-provider will only generate the authorizations.xml file if it does not exist. It also will not modify an already existing authorizations.xml file if you make modifications to the provider. 4. Additional user identities and authorization post accessing your NiFi with your initial admin are done directly with the NiFi UI. Those additions made from the UI will be persisted in the users.xml and authorizations.xml files If above does not help, please start a new community question with the details of your issue. 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

Online	Offline
Last Visited	‎12-02-2025 03:18 AM

Member Since	‎07-30-2019 10:41 AM
Last Visited	‎12-02-2025 03:18 AM
Posts	3,392
Kudos received	1614

Cloudera Community

Re: How to achieve inheritence within Parameter Co...

Re: Cannot access the NiFi Registry from NiFi and ...

Re: Error connecting to NiFi Registry from NiFi UI...

Re: using nifi as a kafka streaming- real-time str...

Re: using nifi as a kafka streaming- real-time str...

Re: Azure AD based authentication for Nifi rest AP...

Re: Looking for a Tool to Simplify Apache NiFi Flo...

Re: Accessing NiFi API with SAML Authentication in...

Re: NiFi UI load balance with HAProxy to CONNECTED...

Re: NiFi UI is Unstable when it connected with cl...

Re: Can we capture the run details of processor an...

Re: Frequent Node Disconnects and Flow Synchroniza...

Re: NiFi node offloading and content storage

Re: Unable to secure NiFi with provided certificat...

Re: Getting [java.io.FileNotFoundException: ../da...