Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Accessing NiFi RestAPI with InvokeHTTP

avatar
New Contributor

Hello All,

 

I am trying to access the NiFi bulletin-board through NiFi API with InvokeHTTP process in order to consume the failure message. Referencing these curl command of this post: Creating NiFi Template via Rest API  I am at the V1.15 with single-user login mode.

My current attempt is:

1. User GenerateFlowFile to simulate the content for API /access/token.
{"Custom Text" : "username=${username}&password=${password}"}
 2. Use InvokeHTTP to request the access token.
HTTP MethodPOST
Remote URLhttps://localhost:8443/nifi-api/access/token
Content Typex-www-form-urlencoded

This will response an access token which will be sent within the header.

 

 3. Use InvokeHTTP to request the bulletin-board.
HTTP MethodGET
Remote URLhttps://localhost:8443/nifi-api/bulletin-board
AuthenticationBearer ${access_token}

This will response the bulletin-board I need.

However

In my current approach, the password will appear in the flowfile content as plain-text witch doesn't  make it a proper approach.

 

Is there a secure way to obtain an access token (i.e. encrypted password) for latter connection?

Am I not understanding the NiFi RestAPI right ?

Is there a better approach to request from the NiFi API through NiFi itself ?

 

Thank you all in advanced.

1 ACCEPTED SOLUTION

avatar
Super Mentor

@oopslemon 


NiFi only encrypts and obscures values in properties that support sensitive properties (so those properties which are specifically coded as sensitive properties like "password" properties). So there is no way at this time to encrypt all or portions of property values not coded as sensitive.  Keep in mind it is not just what is visible in the UI, your unencrypted passwords will be in plaintext with the NiFi flow.xml.gz file as well.

My recommendation to you is to use mutual TLS based authentication instead.  You can create a clientAuth certificate to use in your rest API calls.  Then you need to make sure that your clientAuth certificate is authorized to perform the actions the rest-api call is making.  This is not going to be possible while using the single user login mode as it does not allow you to setup additional users and authorizations.  This single users authentication and authorization providers where added to protect users from unprotected access to their NiFis.  It was not meant to be the desired choice when securing your NiFi.  It is one step above an unsecured default setup that existed prior to NiFi 1.14.  It protects you, but also has limitations that go with its very basic functionality.

So step one is to switch to another method of authentication and authorization to you NiFi.  TLS is always enabled for authentication as soon as NiFi is configured for HTTPS.  You can configure additional authentication methods like ldap/AD.
https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication


The authorizer configured in the authorizers.xml file allows you to establish policies that control user/client permissions.

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#multi-tenant-authorization

 

Then you can configure your invokeHTTP processor to simply use a SSLContextService that you would configure with your clientAuth certificate keystore and a truststore.  The password fields in this controller service would be encrypted.  No more need to constantly get a new bearer token.  All you need to worry about is getting a new client certificate before the old one expires which is typically every 2 years, but that is configurable when you create it and get it signed.


If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post.

Thank you,

Matt

View solution in original post

1 REPLY 1

avatar
Super Mentor

@oopslemon 


NiFi only encrypts and obscures values in properties that support sensitive properties (so those properties which are specifically coded as sensitive properties like "password" properties). So there is no way at this time to encrypt all or portions of property values not coded as sensitive.  Keep in mind it is not just what is visible in the UI, your unencrypted passwords will be in plaintext with the NiFi flow.xml.gz file as well.

My recommendation to you is to use mutual TLS based authentication instead.  You can create a clientAuth certificate to use in your rest API calls.  Then you need to make sure that your clientAuth certificate is authorized to perform the actions the rest-api call is making.  This is not going to be possible while using the single user login mode as it does not allow you to setup additional users and authorizations.  This single users authentication and authorization providers where added to protect users from unprotected access to their NiFis.  It was not meant to be the desired choice when securing your NiFi.  It is one step above an unsecured default setup that existed prior to NiFi 1.14.  It protects you, but also has limitations that go with its very basic functionality.

So step one is to switch to another method of authentication and authorization to you NiFi.  TLS is always enabled for authentication as soon as NiFi is configured for HTTPS.  You can configure additional authentication methods like ldap/AD.
https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication


The authorizer configured in the authorizers.xml file allows you to establish policies that control user/client permissions.

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#multi-tenant-authorization

 

Then you can configure your invokeHTTP processor to simply use a SSLContextService that you would configure with your clientAuth certificate keystore and a truststore.  The password fields in this controller service would be encrypted.  No more need to constantly get a new bearer token.  All you need to worry about is getting a new client certificate before the old one expires which is typically every 2 years, but that is configurable when you create it and get it signed.


If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post.

Thank you,

Matt