Member since
07-30-2019
155
Posts
107
Kudos Received
33
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
7288 | 04-18-2019 08:27 PM | |
2422 | 12-31-2018 07:36 PM | |
4254 | 12-03-2018 06:47 PM | |
1364 | 06-02-2018 02:35 AM | |
3516 | 06-02-2018 01:30 AM |
08-02-2018
07:12 PM
The root pom file located at
nifi/pom.xml in the project structure should be modified so the existing jetty.version value is changed from 9.4.3.v20170317 to 9.4.11.v20180605 . Initial analysis suggests upgrading the Jetty version will cause runtime errors, as their handling of TLD loading has changed and is currently incompatible with how NiFi works.
... View more
08-01-2018
07:18 PM
1 Kudo
You can do this manually on your instance by changing the Jetty dependency version in
nifi/pom.xml ( <jetty.version>9.4.3.v20170317</jetty.version> ). There is an Apache Jira (NIFI-5479) to upgrade this in the core project. Please do not comment on that ticket indicating this is related to a security vulnerability, as the Apache Security Vulnerability Reporting Process must be followed.
... View more
06-02-2018
02:35 AM
David, I would recommend you create an SSLContextService at root which only uses the truststore and ask your users to select that controller service when necessary. If they have requirements to connect to external services which require mutual authentication via TLS client certificates, you may have to create additional controller services with limited keystore access and provide those on a per-instance/user basis. If these are globally-accessible external services (aka not organizationally-signed), you could also provide a generic controller service which uses the Java CA truststore (something like $JAVA_HOME/jre/lib/security/cacerts with default password "changeit").
... View more
06-02-2018
02:27 AM
1 Kudo
Nikita, I believe this is an issue because if you export a public key without ASCII-armoring it (indicated by default by the extension .asc compared to .gpg), the key parsing is performed differently and thus the cipher cannot be formed. NiFi delegates the PGP key parsing to Bouncy Castle's PGPPublicKeyRingCollection class. As noted in the documentation, only a valid key ring is supported here. Is there a reason you cannot convert the single key file into a key ring (see steps here)? There is an open Jira to re-evaluate this handling, but it is not scheduled for work. The solution is to form a valid key ring file from the keys, or use the ASCII-armored public key, which works as you noted.
... View more
06-02-2018
01:30 AM
As @Abdelkrim Hadjidj mentioned, this is not currently possible in NiFi out of the box. You have a few options. Change the file permissions to be accessible by the OS user that is running NiFi. Assuming that user is "nifi", this could be done by adding the "nifi" account to a group with R/W access to the file, or by changing the owner to the "nifi" user (assuming the owner has R/W). This is the recommended solution. You could use an ExecuteStreamCommand or ExecuteProcess processor to run a shell command which reads the contents of the file into a flowfile. Because you are running a shell command, you can use something like "$ echo <other_account_password> | sudo -S -u OTHER_USER more ${path/to/file}". It would be more secure to provide the password in a separate password file (secured via OS permissions) to avoid history leakage, but you can also prepend the command with a space to avoid it showing up in the history. You might be able to use the GetHDFS processor with a configuration file that mapped it to the local file system and allowed user impersonation. This is not recommended and definitely not supported, but potentially technically possible. You could write a custom processor, but Java does not have any API for reading a file as an OS user other than the one that the JVM is running under. You could possibly use the Java FileSystem API to change the OS ownership or permissions on the file, but in that case, #1 is a better solution.
... View more
02-08-2018
12:15 AM
Try removing the users.xml and authorizations.xml files (back these up if you have made other changes prior to securing the application). These files are generated and populated if they are not present at application startup, which means they will be auto-generated the first time the application is run, but not re-generated automatically once they exist. Ensure your files look something like the following:
users.xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tenants>
<groups/>
<users>
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c" identity="CN=alopresto, OU=Apache NiFi"/>
</users>
</tenants>
authorizers.xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizers>
<authorizer>
<identifier>file-provider</identifier>
<class>org.apache.nifi.authorization.FileAuthorizer</class>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Users File">./conf/users.xml</property>
<property name="Initial Admin Identity">CN=alopresto, OU=Apache NiFi</property>
<property name="Legacy Authorized Users File"></property>
</authorizer>
</authorizers>
authorizations.xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizations>
<policies>
<policy identifier="0f4d2dd0-7c8b-39ce-8292-0e459a8dd69f" resource="/flow" action="R">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="9f665453-1e5f-36b4-8f4c-e125491c1fd2" resource="/data/process-groups/4aa66ece-015a-1000-4348-efd94f63c4df" action="R">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="38e2a10c-a75f-3b48-8954-6e5af69c837b" resource="/data/process-groups/4aa66ece-015a-1000-4348-efd94f63c4df" action="W">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="67684272-2833-32e6-954a-d33b7dfc80b2" resource="/process-groups/4aa66ece-015a-1000-4348-efd94f63c4df" action="R">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="ce02741b-adb1-37cf-a818-7d5476e49805" resource="/process-groups/4aa66ece-015a-1000-4348-efd94f63c4df" action="W">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="2148640b-305c-3c53-8a92-5111159729a1" resource="/restricted-components" action="W">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="cc00676b-e0bb-34be-8ae5-89a35dd3ebcb" resource="/tenants" action="R">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="2bf2a497-4045-37d6-8a7f-e8b2753da197" resource="/tenants" action="W">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="9abc4f3b-008c-3ad2-81d3-85410b435c2e" resource="/policies" action="R">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="f4d3b871-7144-3d22-b93d-67110a369647" resource="/policies" action="W">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="e6cdf807-d293-3c5c-8123-0b42c4370a7e" resource="/controller" action="R">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="03947efb-1e7c-3c42-90ac-ba0ebd1e64fd" resource="/controller" action="W">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
<policy identifier="015a1025-3be1-13fc-af08-0f6bf4e9285a" resource="/provenance" action="R">
<user identifier="69d36646-d7cd-33ef-83a7-54d95f67214c"/>
</policy>
</policies>
</authorizations>
... View more
02-07-2018
06:36 PM
It appears that you are specifying a different DN string in your command-line invocation of the TLS Toolkit and your initial admin identity: tls-toolkit.bat standalone -n localhost -C "CN=admin,OU=NIFI"
<property name="Initial Admin Identity">CN=admin, OU=NIFI</property> There is a space between "admin," and "OU=NIFI" in the IAI property definition, but not in the certificate generation command. These strings need to match for NiFi to authenticate the user via client certificate/LDAP/Kerberos.
... View more
01-19-2018
04:03 AM
Hi Alvin, As stated above, I cannot indicate prioritization or scheduling of feature delivery. I am eager to develop this feature, as I am sure many users would like it to be available as well. You can always monitor activity on the Apache NiFi Jira and the mailing lists.
... View more
11-20-2017
06:44 PM
Hi Andy, Your question is ambiguous -- are you looking to use NiFi to make an external HTTP REST request to some other service, and that service requires a username and password, or are you trying to perform behavior in NiFi (adding templates, process groups, etc.) and want to authenticate to NiFi in order to do this? For the former, you'll need to provide the credentials as an Authorization header via an attribute in the InvokeHTTP (or similar) processor. For the latter, you configure NiFi to use one or more authentication mechanisms -- client certificates, LDAP, Kerberos, or OpenID Connect. All but client certificates use a username/password combination, which you can then exchange for an access token as described in the first link you included. Once you have that auth token, you pass it on each request and NiFi verifies it to prove your identity.
... View more
11-08-2017
12:50 AM
1 Kudo
You need the private key and public key to be stored in a Java Keystore (*.jks) file. You can import the PEM-encoded certificate and key into this form by using the following commands: openssl pkcs12 -export -in server.pem -inkey server.key -out server.p12 -name [some-alias] -chain
keytool -importkeystore -deststorepass [yourpassword] -destkeypass [yourpassword] -destkeystore server.jks -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass [passwordfromabove] -alias [some-alias] When creating the temporary PKCS12 keystore, make sure to provide a password at the prompt, or the Java keytool utility will not accept it. Once you have the server.jks file, populate the properties as follows: Keystore file: path/to/server.jks Keystore password: [yourpassword] Key password: [yourpassword] Keystore type: JKS This will allow your NiFi instance/component to present a server certificate identifying itself and encrypt the channel. However, to connect to external HTTPS services, you will also need to provide a truststore. A truststore is a keystore file that contains only public certificates of other services to allow your system (in this case, NiFi) to trust them. If you have custom organizational certificates, you'll need to build your own truststore here. If you are just connecting to generic internet services, the JRE default should be fine: Truststore file: /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/security/cacerts (your JRE path may be different) Truststore password: changeit Truststore type: JKS
... View more