Member since
07-30-2019
3406
Posts
1623
Kudos Received
1008
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 336 | 12-17-2025 05:55 AM | |
| 397 | 12-15-2025 01:29 PM | |
| 405 | 12-15-2025 06:50 AM | |
| 367 | 12-05-2025 08:25 AM | |
| 604 | 12-03-2025 10:21 AM |
04-12-2023
07:22 AM
@davehkd It is difficult for me t say where your configuration has gone wrong with what has been shared I would need to see your authorizers.xml. I see in your output mention of the SingleUserAuthorizer. This authorizer does not support defining additional user for assigning policies. What do you have configured in your nifi.properties for these configuration lines: nifi.security.user.authorizer
nifi.security.user.login.identity.provider If either of these is using the "single-user-provider/authorizer", it is expected that you will not see users in the UI. You'll need to use an authorizer that supports multi user setup like the https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#standardmanagedauthorizer. since you are using user certificates for handling your user authentication. the nifi.security.user.login.identity.provider configuration property should be blank. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-12-2023
07:09 AM
1 Kudo
@cotopaul Your issue is caused by trying to use the ":toDate" and ":format" functions here. These two functions utilize the Java SimpleDateFormat which can not handle your date which uses nanoseconds. You'll want to use a NiFi Expression Language function that supports the Java DateTimeFormatter like ":formatInstant", "toInstant", ":toNanos", or ":toMicros". Using your example: sql.args.2.value = 2023-04-10T10:43:15.794241429+03:00 and an updateAttribute processor configured with this new dynamic property: newformat = ${sql.args.2.value:formatInstant('yyyy-MM-dd HH:mm:ss.SSS','GMT')} Will result in the newformat FlowFile attribute with a value of: 2023-04-10 07:43:15.794 You'll notice the output was designated as being GMT so 3 hours were removed since you had a +03:00 GMT/UTC offset in your original time format. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-12-2023
05:27 AM
@linssab What version of Apache NiFi are you using and where did you download it from? The Single-user-provider and single-user-authorizer where introduced to NiFi starring with Apache NiFi 1.16. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-10-2023
01:49 PM
1 Kudo
@davehkd Your corporate PKI certs are just certs signed by your corporate signing authority. So really nothing needs to change in the configuration of your NiFi. However, you will need to add your corporate signing authorities public certificate to the truststore.jks used by your NiFi. When you access the NiFi UI a mutual TLS exchange occurs. You client (browser) initiates the connection with a client Hello to which the server will respond with a server Hello. In that server hello a list of certificate authorities (comes from CAs in the NiFi truststore) will be provided to back to the client. This tells the client that it will only accept a client certificate signed by one of those authorities. If the client (your browser) has a pki certificate loaded that was signed by one of those trusted authorities, that client certificate can be used to complete the mutual TLS exchange. Much more happens in the Mutual TLS client server handshake, but i'll just stick to the certificate specifics here. NiFi does nothing out of spec when it comes to certificates and NiFi has nothing to do with creating users. You can create your own self signed certificates created via command line tools, use a public signing authority to create signed certificates, or in your case use your corporate signing authority to create certificates. A java keystore is nothing more than a container that can hold 1 too many certificates. Only requirement NiFi has with regards to the keystore it that it contains only 1 PrivateKeyEntry (private cert). The truststore (just another keystore) can contain 1 too many trustedCertEntries (public certs) and often contains many public intermediate and root CAs. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-10-2023
01:33 PM
@ahmedalsaidi You do not need to change the content type since you specify the character set to use in the ExtractText processor which defaults to "UTF-8". If you change the content type or the filename, the built in content viewer in NiFi would be able to display text instead of hex. For example: adding ".txt" to end of filename. When it comes to your matching issue, it would be difficult for me to say what is happening here without a working and non-working sample to look at. In Java regular expressions the "." means any character; however, looking at you hex output screenshot it looks like you really want a literal "." to match. If you want your java regular expression to match the literal ".", then add a "\" (backslash) before each ".". If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-10-2023
11:43 AM
@niclyx While NiFi only supports TLS 1.2 inbound connections, it will support lower TLS version for outgoing. The TLS version used is negotiated between client (NIFi) and server end point during the TSL exchange. The highest level supported by both client and server is what will end up being used. @apmmahesh Authentication and Authorization are two separate process in NiFi. Successful Authentication will result in an user identity string (case sensitive) which is then passed to the authorization process to verify if the that identity string has been authorized for the requested resource. In order to access the NiFI UI, users must be authorized to "view the user interface". The authorization is configured in the authorizers.xml. I am not sure which authorizer or providers you are using. Most commonly used is the managed authorizer, File-access-policy-provider, and File-user-group-provider. But you might also be using the ldap-user-group-provider. The file-access-policy-provider is used to setup necessary policies for the initial admin and nodes (if multi-node NiFi cluster) in an authorizations.xml file. Within the file-access-policy provider you would define your initial admin user identity string "xyz123" so that the polcies need to be admin are assigned to this user identity. Keep in mind the file-access-policy provider will only generate an authorizations.xml file if it does NOT already exist. So if you edit the initial admin or NiFi nodes later, this changes willl not be reflected in the already existing authorizations.xml. You'll need to delete current so new is generated. Before the file access-policy-provider can setup initial admin policies for user "xyz123", the authorizer needs to be able to return that user identity (case sensitive) from one of the configured user-group-provider configured on the authorizers.xml. You can use the file-user-group-provider to manually add user identities to NiFi for purpose of setting up aithorization (in this case their is an initial user identity 1 property you would add "xyz123" to. Optionally you can setup the ldap-user-group-provider to sync user and group identities from your ldap server. Keep in mind that two providers can not return the same identity. So if you are syncing from LDAP, don't configure the same user identity in the file-user-group-provider. here are the relevant Apache NiFi docs on these providers: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#fileusergroupprovider https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#ldapusergroupprovider https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#composite-implementations https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#fileaccesspolicyprovider https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#standardmanagedauthorizer If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-10-2023
11:40 AM
1 Kudo
@apmmahesh Authentication and Authorization are two separate process in NiFi. Successful Authentication will result in an user identity string (case sensitive) which is then passed to the authorization process to verify if the that identity string has been authorized for the requested resource. In order to access the NiFI UI, users must be authorized to "view the user interface". The authorization is configured in the authorizers.xml. I am not sure which authorizer or providers you are using. Most commonly used is the managed authorizer, File-access-policy-provider, and File-user-group-provider. But you might also be using the ldap-user-group-provider. The file-access-policy-provider is used to setup necessary policies for the initial admin and nodes (if multi-node NiFi cluster) in an authorizations.xml file. Within the file-access-policy provider you would define your initial admin user identity string "xyz123" so that the polcies need to be admin are assigned to this user identity. Keep in mind the file-access-policy provider will only generate an authorizations.xml file if it does NOT already exist. So if you edit the initial admin or NiFi nodes later, this changes willl not be reflected in the already existing authorizations.xml. You'll need to delete current so new is generated. Before the file access-policy-provider can setup initial admin policies for user "xyz123", the authorizer needs to be able to return that user identity (case sensitive) from one of the configured user-group-provider configured on the authorizers.xml. You can use the file-user-group-provider to manually add user identities to NiFi for purpose of setting up aithorization (in this case their is an initial user identity 1 property you would add "xyz123" to. Optionally you can setup the ldap-user-group-provider to sync user and group identities from your ldap server. Keep in mind that two providers can not return the same identity. So if you are syncing from LDAP, don't configure the same user identity in the file-user-group-provider. here are the relevant Apache NiFi docs on these providers: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#fileusergroupprovider https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#ldapusergroupprovider https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#composite-implementations https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#fileaccesspolicyprovider https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#standardmanagedauthorizer If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-07-2023
07:59 AM
@axelfulop NiFi Authorization is case sensitive. In your authorizers.xml (responsible for generating the users.xml and authorizationsxml files if and only if they do NOT already exist) you have defined your "initial user identity 1" and "Iniital admin identity" as: axel.fulop@paycomplete.com However, your attached screenshot of the the NiFi UI, shows the authenticated user's 'user identity" was: Axel.Fulop@paycomplete.com NiFi's authorizer will treat these two identities as different user identities since it is case sensitive. There are two ways to resolve this: 1. Update Authorizers.xml entries to use "Axel.Fulop@paycomplete.com", remove users.xml, remove authorizations.xml and then restart NiFi. These two files will get recreated based on new user identity. 2. Add a set of identity mapping properties to the nifi.properties file that will take all authenticated user identities and set them to all lowercase: nifi.security.identity.mapping.pattern.username=^(.*?)$
nifi.security.identity.mapping.value.username=$1
nifi.security.identity.mapping.transform.username=LOWER This would result in the identity string resulting from successful authentication is converted to all lowercase before being passed to the configured NiFi authorizer. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-06-2023
12:19 PM
@Meeran Did you setup sticky sessions in your load balancer? When you provide your ldap username and password, a JWT Token issue to the client which is only valid for use with the specific NiFi node that issued it. So if you enter your username and password and you LB sends next request to a different node to load the flow, the JWT token will not be accepted to identify your user on that other node. Watch the nifi-user.log on all nodes when you attempt to login. In one of those logs you will see authentication success logged for your user. I suspect that then the above exception about "anonymous" is then in a different node's user log. If you are having trouble configuring your load balancer, it would be best to start a new community question for that query so it gets to a wider audience. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more
04-06-2023
11:55 AM
@drewski7 I have not been able to reproduce the NiFi Registry URL truncation yet using Apache NiFi 1.19 I have installed. Couple things to check/try: 1. Apache NiFi 1.16.0 is about the time NiFi switched to using the flow.json.gz to load the flow in to memory at startup. Every time you make a change via the NiFi Ui, the current flow.json.gz is archived and new flow.json.gz is created. After fixing your NiFi-Registry URL, go inspect the flow.json.hgz file and see if the URL is being truncated when being persisted out to the flow.json.gz file. This file is only read at startup to load the flow back into NiFi's heap memory. The Registry clients will be at very beginning of the flow.json.gz 2. Try adding the port to the URL and see if that makes a difference (https://xyz.com:443/gateway/registry/nifi-registry-app/nifi-registry-api ). If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt
... View more