Skip to main content
Krish98
Krish98
Bronze ⭐️⭐️⭐️
August 1, 2025
Solved

Accessing NiFi API with SAML Authentication in NiFi 1.28.1

 Hi Cloudera Community/@@MattWho,

I'm currently working with Apache NIFI version 1.28.1 and have successfully configured SAML authentication using an  Okta for UI login.

I now need to access the NIFI REST API (/nifi-api) programmatically, but I'm facing challenges due to the nature of SAML being browser-based. Specifically, I’d like to know:

  • What are the supported or recommended methods to access the NIFI API when SAML authentication is enabled?
  • Is there a way to retrieve or reuse the JWT token issued after SAML login for API calls?
  • Can NIFI processors or external scripts be used to automate token retrieval or API access in this setup?
  • Are there any best practices or alternative authentication mechanisms (e.g., client certificates or hybrid setups) that can be used alongside SAML for API access?

Any guidance or examples would be greatly appreciated!

Thanks in advance.

MattWho
MattWhoAnswer
Titanium ⭐️⭐️⭐️
August 1, 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



View in thread

1 reply

MattWho
Titanium ⭐️⭐️⭐️
MattWhoAnswer
Titanium ⭐️⭐️⭐️
August 1, 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



Translate
Terms & ConditionsAccessibility statement