Member since
07-30-2019
3414
Posts
1623
Kudos Received
1008
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 415 | 12-17-2025 05:55 AM | |
| 476 | 12-15-2025 01:29 PM | |
| 507 | 12-15-2025 06:50 AM | |
| 393 | 12-05-2025 08:25 AM | |
| 648 | 12-03-2025 10:21 AM |
09-19-2023
07:15 AM
@edim2525 If your NiFi is already secured that means you have already using authentication and authorization is some form of configuration. So depending in your current secure setup configuration, the guidance you may need will vary. There are multiple NiFi configuration files that establish the configurations for authentication and authorization (While authorization is dependent on successful authentication, the processes are executed separately). nifi.properties login-identity-providers.xml authorizers.xml Understanding your current setup is important for giving proper guidance to change configuration. For authenticating with LDAP/AD users, you'll want to use the ldap-provider in the login-identity-providers.xml For authorization you can NOT use default "single-user-authorizer" in the authorizers.xml authorizers.xml. You'll need to switch to a different provider like the Standard Managed Authorizer. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-19-2023
07:00 AM
1 Kudo
@SandyClouds The "Jolt Specification" property in the JoltTransformJson processor supports NiFi Expression Language (will be evaluated using flow file attributes and variable registry). This means that any attribute present on the FlowFile passed to the JoltTransform processor can be used in the spec. So if you have an upstream processor adding an attribute to your FlowFile with the attribute name "customer_id", you can simply use NiFi Expression Language in your spec to pull in that attributes value. NiFi Parameters are defined using "#{<parameter name>}" which will look up that parameter in the parameter context defined on the NiFi Process Group and return its value. NiFi Expression language is defined by starting with "${" and ending with "}". Between that you can bring in an attributes value, apply NiFi Expression Language functions against an attributes value, etc. Simplest NiFi Expression Language statement would be "${customer_id}", which will look for an attribute in the FlowFile being processed and return its value. We refer to "customer_id" as the "subject" in that NiFi EL. NiFi EL does have a bunch of subjectless functions like "now()" that you are using, but more typical use cases start with a subject (FlowFile attribute). I strongly encourage you to read through the linked NiFi EL guide to help you better understand the complexity and many ways you can used NiFi EL statements. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-19-2023
06:45 AM
@Kumar_ The more detail you can provide, the better chance with getting a response. Sharing details like: Version of NiFi being used. full error and stack trace logged in the nifi-app.log. processor configuration details (if applicable). Matt
... View more
09-19-2023
06:33 AM
@Anderosn So MergeContent does just that, merges the content of all FlowFiles being merged. I am not sure how often your GenerateFlowFile processor executes, but when it does execute it will create a FlowFile with a unique filename (unless you set the filename in the GenerateFlowFile processor via a dynamic property). The produced data by the GenerateFlowFile is routed is routed as a FlowFile to one of the success relationships and a clone FlowFile is routed to the other success relationship in your dataflow (both FlowFiles have same "filename" but different flowfile uuids). The "filename" attribute can be used in the MergeContent processor in the "Correlation Attribute Name" property. Then you can set min num entries to "2". This will make sure both FlowFiles with same value in the filename attribute will get allocated to same bin. The MergeContent property "Attribute Strategy" will need to be set to "Keep All Unique Attributes" so that the final merged FlowFile will include the new token attribute. Now we have to deal with the content. What we need to make sure is that the FlowFile used to fetch the token has no content before being routed to mergeContent processor. For that you can use the ModifyBytes processor and set "Remove all content" to "true" after your EvaluateJsonPath processor. Removing the content does not remove the FlowFile metadata/attributes, so this now 0 byte FlowFile will still have its filename value and token attribute with value. ------- Now with above suggestion for your existing dataflow as an option, there are probably many other dataflow designs to accomplish this. Since you are using GenerateFlowFile to create the content needed for your final invokeHTTP, I'd go a different route that does not need a MergeContent processor. GenerateFlowFIle (custom content needed to fetch token) --> InvokeHTTP (get Token) --> EvaluateJsonPath (extract token from content to attribute) --> replaceText ( ("Replacement Strategy"="always replace", "Evaluation mode"="Entire text", "replacement value"=<content needed for your final rest-api call>) --> InvokeHTTP (you final rest-api endpoint request). The above removes need for MergeContent or dealing with multiple paths. You have a single process flow where any failure in along the path does not result in potential of orphaned binned FlowFile at your MergeContent processor. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-19-2023
05:59 AM
@pacman The "unable to find valid certificate path to request target" is caused when trust can not be established in the TLS handshake. This is the result of missing trusted cert entry(s) in the truststore (missing or incomplete trust chain). When you used the toolkit to create your certficates, it also built the corresponding truststore with the required trust chain. The HTTP 403 exception indicated not authorized while the 401 indicated failed authentication. Authentication was determined through the mutualTLS handshake between the clientAuth certificate presented from the keystore configured in Ranger and serverAuth certificate presented by NiFi. The DN from the clientAuth certificate is used as the user identity in the authentication (keep in mind that during authentication the final user identity is determined after evaluating the user identity returned during authentication against any configured Identity mapping patterns configured in the nifi.properties file. If you inspect the nifi-user.log, you should see attempt to access the .../resources NiFi endpoint (This is endpoint where Ranger is trying to fetch the list of NiFi resource identifiers). In that nifi-user.log you will see the actual post authentication user identity being used (full certificate DN or some valued mapped from that full DN). This is where my early response about needing to authorize the ranger clientAuth certificate user identity in Ranger manually against the "/resources" NiFi resource Identifier is needed. So you'll need to make sure the exact user identity from the nifi-user.log is added as a user in Ranger and added to a NiFi service policy in ranger giving that user authorization for "/resources". Once NiFi downloads the updated policy json from Ranger, Ranger NiFi service client will now be authorized to fetch all NiFi Resource Identifiers from the /resources endpoint. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-18-2023
12:45 PM
@Kumar_ Check the configuration value boxes to see if you added a line return. If the configuration pop-up box shows more then just a "1" line then you have a lone return at the end of line "1". Click on line to and hit delete to get rid of the line return if present. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-18-2023
12:16 PM
@LKB I'd expect a full stack trace in the nifi-app.log following that ERROR. The ldap-provider is configured inside the login-identity-providers.xml file. Does your LDAP Manager password happen to contain any XML special characters? If so, you should escape them. https://xml.silmaril.ie/specials.html Have you tried using ldapsearch to manually make a connection to your LDAPS from the server where you have NiFi installed using same manager DN, Manager password, and keystore and trustsore? Was it successful? If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-18-2023
12:02 PM
@pacman Seems odd to me that in the shared Ranger configuration you have configured a truststore where Ranger is expecting a keystore. Then you have your truststore configured with the keystore instead of truststore. The Ranger service is attempting to connect to NiFi's /resource NiFi resource Identifier endpoint in order to obtain an up-to-date list of NIFi Resource Identifiers in order to simplify creating new policies in Ranger for NiFi. The endpoint requires authorization and NiFi gets its authorization from the policies it downloads from Ranger. So we have a which comes first, chicken or the egg, scenario here. You will need to authorize the clientAuth certificate configure in the keystore for READ on the "/resources" NiFi Resource Identifier before Ranger will be able to fetch all the rest of the NiFi resource Identifiers. Before that is possible, Ranger will need to be able to successfully negiotate a mutualTLS handshake with NiFi. This does not require that Ranger server is SSL enabled, just that the NiFi service within Ranger is configured with a keystore and truststore capable of facilitating that mutualTLS handshake with the secured NiFi. Also keep in mind that Ranger service user is executing this client connection to NiFi and thus the keystore and truststore configured must be accessible by the Ranger service user. The Truststore used in Ranger NiFi service must contain the complete trust chain for all the NiFi cluster node's certificates. The ClientAuth certificate in the keystore used in the Ranger NiFi service must be trusted by all the NiFi cluster nodes (meanings its complete trust chain must exist in NiFi's truststore configured in the nifi.properties file). If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-18-2023
11:44 AM
@manishg The ListFile does not pickup any files. It simply generates a zero content NiFI FlowFile for each file found in the target directory. That FlowFile only has metadata about the target content. The FetchFile processor utilizes that metadata to fetch that actual content and add it to the FlowFile. The value added here happens when you have a lot target files to ingest. To avoid having all the disk I/o related to that content on one node, you can redistribute the zero byte FlowFiles across all nodes so that each node now in a distributed way fetches the content (This works assuming that same target directory is mounted on all NiFi cluster nodes). As @SAMSAL shared you could use Process Group (PG) FlowFile concurrency to accomplish the processing of one FlowFile at a time. The ListFile will still continue to list all FlowFiles in target directory (writes state and continues to list new files as they get added to input directory). You can then feed the outbound connection of your ListFile to a PG configured with "Single FlowFile Per Node" FlowFile concurrency. This will prevent any other FlowFile queued between ListFile and the PG to enter the PG until the first FlowFile has processed through that PG. So your first processor inside the PG would be your FetchFile processor. Now if you were to configure Load Balanced Connection on that connection between ListFile and the PG, You would end up with each node in your NiFi cluster processing a single File at a time. This gives you some concurrency if you want it. However, if you have a strict one file at a time, you would not configure load balanced connection. Hope this helps, Matt
... View more
09-15-2023
11:12 AM
@LKB I am not clear what you mean by "NiFi rejects" it. What is the exact exception you are seeing. NiFi does not reject anything, the ldap endpoint would be what would be responding to the query. The "{0}" is replaced with the username string you enter in the "user" field presented by NiFi. So let's assume you login with "user_admin". Your configured LDAP endpoint would be queried for user with "sAMAccountName=user_admin" as an attribute. I would get the ldap listing for your user_admin user from ldap server and verify that "sAMAccountName=user_admin" exists. sAMAccountName is an attribute more commonly associated with Active Directory (AD), but can be added to LDAP as a useable attribute with some custom ldifs. Two authentication happen here: First is the Manager DN along with Manager password is used to facilitate a connection to your ldap. Then the supplied username via login UI is used to lookup the specific user record for password verification. Additionally, since you are using LDAPS instead of LDAP, you are enabling a TLS encrypted connection to your LDAPS. So something else you'll want to verify is that the keystore and truststore you configured in your ldap-provider contains the necessary entries to facilitate that successful TLS connection. Something other configs that strikes me as incorrect: 1. Your user DN is "uid=user_admin,OU=USERS,DC=abc,DC=com"; however, your configured user search base is "DC=abc,DC=net". That means your user you are trying to authenticate would not be found under that search base. 2. Your LDAPS url is missing the port number "ldaps://test.com:<port>" (commonly 636 and 3269 are defaults for ldaps). If your LDAP support unencrypted connections you could change your "Authentication Strategy" from "START_TLS" to "SIMPLE" and then set your LDAP URL to ldap://test.com:389 (389 is default unencrypted port). Make sure you are checking your nifi-app.log and nifi-user.log for any exceptions that may be thrown as you try to login to help you troubleshoot further. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more