You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by scotty <yt...@msn.com> on 2020/09/07 08:28:17 UTC
Securing NiFI behind a proxy (NGINX).
Hi,
1. I had an usecured NiFi setup running: "Client > https > reverse proxy >
http > NiFi"
2. I tried to secure it using the instructions at
https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit.
Certificates were generate as follows:
a. ./bin/tls-toolkit.sh standalone -n '<my domain name>'
b. ./home/scotty/nifi-toolkit-1.9.1/bin/tls-toolkit.sh standalone -C
'CN=my_username,OU=NiFi'
3. added CN=my_username,OU=NiFi in authorizers.xml (users.xml and
authorizations.xml appear correct)
4. The response I'm getting at the NiFI URL is 'Insufficient Permissions:
Unknown user with identity 'CN=localhost, OU=NIFI'. Contact the system
administrator.'
5. I'm getting the same message from whatever computer I try to access the
UI from, whether it has the user certificate installed or not. So who's
making the request to authenticate?
6. nifi-user.log shows as follows:
INFO [NiFi Web Server-84] o.a.n.w.s.NiFiAuthenticationFilter Attempting
request for (CN=localhost, OU=NIFI) GET https://<my domain
name>/nifi-api/flow/current-user (source ip: <ip address>)
2020-08-30 15:43:45,820 INFO [NiFi Web Server-84]
o.a.n.w.s.NiFiAuthenticationFilter
Authentication success for CN=localhost, OU=NIFI
2020-08-30 15:43:45,831 INFO [NiFi Web Server-84]
o.a.n.w.a.c.AccessDeniedExceptionMapper identity[CN=localhost, OU=NIFI],
groups [] does not have permission to access the requested resource. Unknown
user with identity 'CN=localhost, OU=NIFI'. Returning Forbidden response
7. My NiFI truststore.jks shows the following:
keystore contains 1 entry
Alias name: nifi-cert
Entry type: trustedCertEntry
Owner: CN=localhost, OU=NIFI
Issuer: CN=localhost, OU=NIFI
8. When I tried to use the X-ProxiedEntitiesChain header in my NGINX config,
I got an "untrusted proxy" error when trying to access the NiFI UI.
Was I suppsed to secure NiFi without the reverse proxy and then setup the
proxy through the NiFI UI (as discussed in the following)?
"If NiFi is running securely, any proxy needs to be authorized to proxy user
requests. These can be configured in the NiFi UI through the Global Menu.
Once these permissions are in place, proxies can begin proxying user
requests. The end user identity must be relayed in a HTTP header. For
example, if the end user sent a request to the proxy, the proxy must
authenticate the user. Following this the proxy can send the request to
NiFi. In this request an HTTP header should be added as follows."
9. Was I supposed to generate a certificate for the proxy (as discussed in
this Apache Knox tutorial)?
https://risdenk.github.io/2018/03/18/apache-knox-proxying-apache-nifi.html
Any guiidance appreciated.
Thanks.
--
Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Re: Flow Migration Invalidates Processors (wrong GUID)
Posted by jgunvaldson <jg...@cox.net>.
For NIFI we are using HortonWorks HDF Dataflow Powered by Apache NiFi Version 1.9.0 - 1.9.0.3.4.1.1-4 built 05/01/2019 02:15:30 UTC
I just checked Ambari (Our NIFI registry is using — Version: 3.4.1.1-4
But this is good news if there is an upgrade forthcoming with these features! Would speed up and solve a lot!
Good info!
Best Regards
~John
> On Sep 8, 2020, at 10:18 AM, Bryan Bende <bb...@gmail.com> wrote:
>
> I believe it is NiFi 1.10.0 and registry 0.5.0 that will give you the matching behavior described by Mark.
>
> On Tue, Sep 8, 2020 at 1:11 PM Mark Payne <markap14@hotmail.com <ma...@hotmail.com>> wrote:
> John,
>
> What version of NiFi/Registry are you using?
>
> NiFi will first attempt to match “external Controller Services” (meaning external to the Process Group being imported) based on an ID, as you describe. But with the latest version of NiFi (I do not recall off the top of my head whether or not a specific version of the Registry is required), if no Controller Service can be found with the appropriate ID, it will try to match them up by Controller Service name and type. So, if you have a DBCPConnectionPool named “My Connection Pool” in your first environment, and you want to import that into a second environment, you can create a DBCPConnectionPool in the second environment with the name “My Connection Pool” and then when you import your flow, NiFi should handle matching up the Controller Service by name.
>
> Hope this helps!
> -Mark
>
>
>> On Sep 8, 2020, at 12:59 PM, jgunvaldson <jgunvaldson@cox.net <ma...@cox.net>> wrote:
>>
>> We are working through various alternatives for migration of flows from our old DEV environment to other (new DEV, QA and PROD)
>>
>> Currently the approach we use invalidates all processors that use controller services established on root and domain flow level (import of FLOW does not duplicate GUID from root canvas) - in a sense using the process of creating a new Processor and import from old registry bucket.
>>
>> Problem starts with the way NiFi stores processor information in registry by referencing controller services by ID and parentGroupId.
>>
>> However, controller services and domain processor groups in the new DEV, QA or PROD environments were created using UI (in preparation , and they are of course assigned a different ID (GUID). Thus, when attempting the import process, the Import process fails to match them and does not set controller services properties for processors that use those controller services which leaves those processors in invalid state.
>>
>> We are looking at various multiple potential solutions:
>>
>> Developers fix their flows manually. This would introduce a large workload (in my case one flow would have 200+ processor to be fixed) for developers that rely on controller services established on root level (database connections, distributed map cache etc)
>> We have a team run automation scripts to match controller services by name (how often to run script, after each import?)
>> We administrators change IDs in new DEV, QA or PROD flow definition file to match old DEV environment
>> We administrators create new DEV, QA ir ORID environment using truncated (root and domain flow) flow definition file from old DEV environment
>> We administrators create a process to create controller services and domains that does not rely on NiFi UI in a way that will ensure that all root/domain level controller services and root/domain level flows have the same ID
>> These are some ideas we have - but I am very interested in how the community has solved importing your flows from one (old) environment into a newly created environment, when the controller services GUID will not match on import - and invalidates the flow - and developer may have to “FIX” hundreds of properties?
>>
>>
>> Thanks in advance
>> ~John Gunvaldson
>>
>
Re: Flow Migration Invalidates Processors (wrong GUID)
Posted by Bryan Bende <bb...@gmail.com>.
I believe it is NiFi 1.10.0 and registry 0.5.0 that will give you the
matching behavior described by Mark.
On Tue, Sep 8, 2020 at 1:11 PM Mark Payne <ma...@hotmail.com> wrote:
> John,
>
> What version of NiFi/Registry are you using?
>
> NiFi will first attempt to match “external Controller Services” (meaning
> external to the Process Group being imported) based on an ID, as you
> describe. But with the latest version of NiFi (I do not recall off the top
> of my head whether or not a specific version of the Registry is required),
> if no Controller Service can be found with the appropriate ID, it will try
> to match them up by Controller Service name and type. So, if you have a
> DBCPConnectionPool named “My Connection Pool” in your first environment,
> and you want to import that into a second environment, you can create a
> DBCPConnectionPool in the second environment with the name “My Connection
> Pool” and then when you import your flow, NiFi should handle matching up
> the Controller Service by name.
>
> Hope this helps!
> -Mark
>
>
> On Sep 8, 2020, at 12:59 PM, jgunvaldson <jg...@cox.net> wrote:
>
> We are working through various alternatives for migration of flows from
> our old DEV environment to other (new DEV, QA and PROD)
>
> Currently the approach we use invalidates all processors that use
> controller services established on root and domain flow level (import of
> FLOW does not duplicate GUID from root canvas) - in a sense using the
> process of creating a new Processor and import from old registry bucket.
>
> Problem starts with the way NiFi stores processor information in registry
> by referencing controller services by ID and parentGroupId.
>
> However, controller services and domain processor groups in the new DEV,
> QA or PROD environments were created using UI (in preparation , and they
> are of course assigned a different ID (GUID). Thus, when attempting the
> import process, the Import process fails to match them and does not set
> controller services properties for processors that use those controller
> services which leaves those processors in invalid state.
>
> We are looking at various multiple potential solutions:
>
>
> - Developers fix their flows manually. This would introduce a large
> workload (in my case one flow would have 200+ processor to be fixed) for
> developers that rely on controller services established on root level
> (database connections, distributed map cache etc)
> - We have a team run automation scripts to match controller services
> by name (how often to run script, after each import?)
> - We administrators change IDs in new DEV, QA or PROD flow definition
> file to match old DEV environment
> - We administrators create new DEV, QA ir ORID environment using
> truncated (root and domain flow) flow definition file from old DEV
> environment
> - We administrators create a process to create controller services and
> domains that does not rely on NiFi UI in a way that will ensure that all
> root/domain level controller services and root/domain level flows have
> the same ID
>
> These are some ideas we have - but I am very interested in how the
> community has solved importing your flows from one (old) environment into a
> newly created environment, when the controller services GUID will not match
> on import - and invalidates the flow - and developer may have to “FIX”
> hundreds of properties?
>
>
> Thanks in advance
> ~John Gunvaldson
>
>
>
Re: Flow Migration Invalidates Processors (wrong GUID)
Posted by Mark Payne <ma...@hotmail.com>.
John,
What version of NiFi/Registry are you using?
NiFi will first attempt to match “external Controller Services” (meaning external to the Process Group being imported) based on an ID, as you describe. But with the latest version of NiFi (I do not recall off the top of my head whether or not a specific version of the Registry is required), if no Controller Service can be found with the appropriate ID, it will try to match them up by Controller Service name and type. So, if you have a DBCPConnectionPool named “My Connection Pool” in your first environment, and you want to import that into a second environment, you can create a DBCPConnectionPool in the second environment with the name “My Connection Pool” and then when you import your flow, NiFi should handle matching up the Controller Service by name.
Hope this helps!
-Mark
On Sep 8, 2020, at 12:59 PM, jgunvaldson <jg...@cox.net>> wrote:
We are working through various alternatives for migration of flows from our old DEV environment to other (new DEV, QA and PROD)
Currently the approach we use invalidates all processors that use controller services established on root and domain flow level (import of FLOW does not duplicate GUID from root canvas) - in a sense using the process of creating a new Processor and import from old registry bucket.
Problem starts with the way NiFi stores processor information in registry by referencing controller services by ID and parentGroupId.
However, controller services and domain processor groups in the new DEV, QA or PROD environments were created using UI (in preparation , and they are of course assigned a different ID (GUID). Thus, when attempting the import process, the Import process fails to match them and does not set controller services properties for processors that use those controller services which leaves those processors in invalid state.
We are looking at various multiple potential solutions:
* Developers fix their flows manually. This would introduce a large workload (in my case one flow would have 200+ processor to be fixed) for developers that rely on controller services established on root level (database connections, distributed map cache etc)
* We have a team run automation scripts to match controller services by name (how often to run script, after each import?)
* We administrators change IDs in new DEV, QA or PROD flow definition file to match old DEV environment
* We administrators create new DEV, QA ir ORID environment using truncated (root and domain flow) flow definition file from old DEV environment
* We administrators create a process to create controller services and domains that does not rely on NiFi UI in a way that will ensure that all root/domain level controller services and root/domain level flows have the same ID
These are some ideas we have - but I am very interested in how the community has solved importing your flows from one (old) environment into a newly created environment, when the controller services GUID will not match on import - and invalidates the flow - and developer may have to “FIX” hundreds of properties?
Thanks in advance
~John Gunvaldson
Flow Migration Invalidates Processors (wrong GUID)
Posted by jgunvaldson <jg...@cox.net>.
We are working through various alternatives for migration of flows from our old DEV environment to other (new DEV, QA and PROD)
Currently the approach we use invalidates all processors that use controller services established on root and domain flow level (import of FLOW does not duplicate GUID from root canvas) - in a sense using the process of creating a new Processor and import from old registry bucket.
Problem starts with the way NiFi stores processor information in registry by referencing controller services by ID and parentGroupId.
However, controller services and domain processor groups in the new DEV, QA or PROD environments were created using UI (in preparation , and they are of course assigned a different ID (GUID). Thus, when attempting the import process, the Import process fails to match them and does not set controller services properties for processors that use those controller services which leaves those processors in invalid state.
We are looking at various multiple potential solutions:
Developers fix their flows manually. This would introduce a large workload (in my case one flow would have 200+ processor to be fixed) for developers that rely on controller services established on root level (database connections, distributed map cache etc)
We have a team run automation scripts to match controller services by name (how often to run script, after each import?)
We administrators change IDs in new DEV, QA or PROD flow definition file to match old DEV environment
We administrators create new DEV, QA ir ORID environment using truncated (root and domain flow) flow definition file from old DEV environment
We administrators create a process to create controller services and domains that does not rely on NiFi UI in a way that will ensure that all root/domain level controller services and root/domain level flows have the same ID
These are some ideas we have - but I am very interested in how the community has solved importing your flows from one (old) environment into a newly created environment, when the controller services GUID will not match on import - and invalidates the flow - and developer may have to “FIX” hundreds of properties?
Thanks in advance
~John Gunvaldson
Re: Securing NiFI behind a proxy (NGINX).
Posted by Sushil Kumar <sk...@gmail.com>.
Hey Scott
Looks like it started working for you.
It will be helpful if you can document and share how you proceeded and
problems you faced.
Thanks
Sushil Kumar
On Fri, Sep 25, 2020 at 2:31 AM scotty <yt...@msn.com> wrote:
> Hi Kevin,
>
> Referencing my previous post:
>
> 1. The header folding problem was solved, using
> proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;
>
> nifi-user.log:
> "Attempting request for (<CN=clientname,OU=NiFi><CN=reverseproxy,
> OU=NiFi>)
> Authentication success for CN=clientname,OU=NiFi"
>
> 2. But then I also got
>
> "identity[CN=clientname,OU=NiFi], groups[] does not have permission to
> access the requested resource.
> Unknown user with identity 'CN=clientname,OU=NiFi'. Returning Forbidden
> response."
>
> That was because NGINX now removed the space between CN and OU.
>
> So I had to create a new NiFi user without the space to match NGINX's
> presentation of the FQDN, and have to remember to create user FQDNs without
> spaces in the future.
>
> I don't know why I have to use both the 'proxy_set_header
> X-ProxiedEntitiesChain' (as shown in Mr. Kawamura's example) as well as the
> 'proxy_set_header X-SSL-CERT' directives, but it works.
>
> Anyway, thanks for your guidance which kept me from going down more rabbit
> holes than I already had.
>
> Scott
>
>
>
>
> --
> Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
>
Re: Securing NiFI behind a proxy (NGINX).
Posted by scotty <yt...@msn.com>.
Hi Kevin,
Referencing my previous post:
1. The header folding problem was solved, using
proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;
nifi-user.log:
"Attempting request for (<CN=clientname,OU=NiFi><CN=reverseproxy, OU=NiFi>)
Authentication success for CN=clientname,OU=NiFi"
2. But then I also got
"identity[CN=clientname,OU=NiFi], groups[] does not have permission to
access the requested resource.
Unknown user with identity 'CN=clientname,OU=NiFi'. Returning Forbidden
response."
That was because NGINX now removed the space between CN and OU.
So I had to create a new NiFi user without the space to match NGINX's
presentation of the FQDN, and have to remember to create user FQDNs without
spaces in the future.
I don't know why I have to use both the 'proxy_set_header
X-ProxiedEntitiesChain' (as shown in Mr. Kawamura's example) as well as the
'proxy_set_header X-SSL-CERT' directives, but it works.
Anyway, thanks for your guidance which kept me from going down more rabbit
holes than I already had.
Scott
--
Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Re: Securing NiFI behind a proxy (NGINX).
Posted by scotty <yt...@msn.com>.
Hi Kevin,
1. nginx.conf
ssl_client_certificate 'path'/nifi-cert.pem;
ssl_verify_client on;
nginx -t
nginx.conf test is successful
2. Enter URI to NiFi: Bad Message 400, reason: Header Folding
3. Researching the error, I found this regarding NGINX non-compliance with
RFC7230 and the problem that creates with Jetty. The solution stated here is
to change the httpCompliance parameter to non RFC7230 compliance
"This sets the http compliance level used by Jetty when parsing http, this
can be useful when using a non-RFC7230 compliant front end, such as nginx,
which can produce multi-line headers when forwarding client certificates
using proxy_set_header X-SSL-CERT $ssl_client_cert;"
https://www.javadoc.io/doc/io.dropwizard/dropwizard-jetty/2.0.0-rc4/io/dropwizard/jetty/HttpConnectorFactory.html
There is a further discussion on NGINX RFC7230 non-compliance here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=483795
Is there some other way to forward client certificates besides using
proxy_set_header X-SSL-CERT $ssl_client_cert; or will I have to make this
modification in Jetty?
note: I tried setting proxy_set_header X-SSL-CERT $ssl_client_raw_cert
('raw_cert' instead of just 'cert') and got a Bad Message 400, reason:
Illegal character LF=\n
Thanks.
Scott
--
Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Re: Securing NiFI behind a proxy (NGINX).
Posted by Kevin Doran <kd...@apache.org>.
Hi Scott,
It looks like you are close to a working setup. Given that your client certificate was generate by NiFi Toolkit, I believe the ssl_client_certificate directive requires the CA Cert generated by NiFi Toolkit in PEM format (should be nifi-cert.pem). Personally, I’ve never run Nginx with a server cert (ssl_certificate) and client cert (ssl_client_certificate) that are signed by different CA’s (in your case, server from lets encrypt and client from nifi toolkit), but I *think* it should work.
If all is working correctly, you should see something like the following in the nifi-user.log:
GET request for (<CN=exampleUiClient, OU=NiFi><CN=reverse_proxy, OU=NiFi>)
Authentication success for CN=exampleUiClient, OU=NiFi
In other words, where the proxied identity being passed is now <> (indicating anonymous), the client certificate DN should be present.
Hope this helps,
Kevin
> On Sep 24, 2020, at 03:51, scotty <yt...@msn.com> wrote:
>
> Hi Kevin,
>
> Thanks for the information and the links.
>
> Looking at the standalone example from the link that you sent, I'm not sure
> what the ssl_client_certificate directive should be.
>
> In my ssl_certificate directive is a letsencrypt DV certificate, and in my
> proxy_ssl_certificate is the nifi-toolkit generated certificate for my
> reverse proxy (both in the server block of the nginx.conf file).
>
> Accordingly, my nifi-toolkit generated client certificate isn't working in
> the ssl_client certificate directive.
>
> These are what the logs look like with the ssl_client_certificate, and,
> hence, the ssl_verify_client directives commented out:
>
> 1. NGINX access.log:
>
> "GET /nifi-api/flow/current-user HTTP/1.1" 401 85 "https://<uri>"
> "GET /nifi/login HTTP/1.1" 200 832 "https://<uri>"
> "GET /nifi/css/nf-login-all.css?1.9.1 HTTP/1.1" 200 2426 "https://uri/login"
> "GET /nifi-api/access/config HTTP/1.1" 200 54 "https://<uri>/login"
> "GET /nifi-api/access HTTP/1.1" 200 108 "https://<uri>/login"
>
> 2. NIFI nifi-user.log:
>
> GET request for (<><CN=reverse_proxy, OU=NiFi>)
> Authentication success for anonymous
> anonymous does not have permission to access the requested
> resource...Unknown user with identity 'anonymous.' Returning Unauthorized
> response.
>
>
> 3. NiFI User Interface shows "Success: You are already logged in"
>
>
> Note: (my reverse proxy only has proxy user requests permissions in NiFi,
> while my client has the UI access permissions)
>
>
> Any further guidance is appreciated.
>
> Thanks again.
>
> Scott
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Re: Securing NiFI behind a proxy (NGINX).
Posted by scotty <yt...@msn.com>.
Hi Kevin,
Thanks for the information and the links.
Looking at the standalone example from the link that you sent, I'm not sure
what the ssl_client_certificate directive should be.
In my ssl_certificate directive is a letsencrypt DV certificate, and in my
proxy_ssl_certificate is the nifi-toolkit generated certificate for my
reverse proxy (both in the server block of the nginx.conf file).
Accordingly, my nifi-toolkit generated client certificate isn't working in
the ssl_client certificate directive.
These are what the logs look like with the ssl_client_certificate, and,
hence, the ssl_verify_client directives commented out:
1. NGINX access.log:
"GET /nifi-api/flow/current-user HTTP/1.1" 401 85 "https://<uri>"
"GET /nifi/login HTTP/1.1" 200 832 "https://<uri>"
"GET /nifi/css/nf-login-all.css?1.9.1 HTTP/1.1" 200 2426 "https://uri/login"
"GET /nifi-api/access/config HTTP/1.1" 200 54 "https://<uri>/login"
"GET /nifi-api/access HTTP/1.1" 200 108 "https://<uri>/login"
2. NIFI nifi-user.log:
GET request for (<><CN=reverse_proxy, OU=NiFi>)
Authentication success for anonymous
anonymous does not have permission to access the requested
resource...Unknown user with identity 'anonymous.' Returning Unauthorized
response.
3. NiFI User Interface shows "Success: You are already logged in"
Note: (my reverse proxy only has proxy user requests permissions in NiFi,
while my client has the UI access permissions)
Any further guidance is appreciated.
Thanks again.
Scott
--
Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Re: Securing NiFI behind a proxy (NGINX).
Posted by Kevin Doran <kd...@apache.org>.
Hi,
Your understanding is correct: In order to get the connections you want, NGINX will have to be recognized by NiFi as an authorized proxy. The client certificate DN will be used for each request, provided NGINX terminates that TLS connection from the client and passes the DN of the certificate in the X-ProxiedEntitiesChain header to NiFi.
There are a few examples here:
https://github.com/ijokarumawak/nifi-reverseproxy/tree/master/nginx <https://github.com/ijokarumawak/nifi-reverseproxy/tree/master/nginx>
Here is an example of configuring NGINX to pass the client Cert DN to NiFi:
https://github.com/ijokarumawak/nifi-reverseproxy/blob/master/nginx/standalone-secure-http/nginx.conf <https://github.com/ijokarumawak/nifi-reverseproxy/blob/master/nginx/standalone-secure-http/nginx.conf>
The FQDN of NGINX should match the external hostname of the machine (i.e., what the client uses to send requests).
Hope this helps,
Kevin
> On Sep 16, 2020, at 02:04, scotty <yt...@msn.com> wrote:
>
> Hi Vijay,
>
> After realizing that the reverse proxy was the problem, I've got NiFi,
> standalone, secured with certificates by removing the reverse proxy out of
> the mix.
>
> Is there some example, somewhere, of using a NGINX reverse proxy so that I
> can have the following setup?
>
> client > https > NGINX > https > NiFi
>
> My understanding is that NGINX needs a client certificate and that the FQDN
> of that certificate needs to be setup to proxy user requests in the NiFi UI.
> I've done both of these things as well as setup the nifi.web.proxy.host and
> nifi.web.proxy.context.path in the nifi.properties file.
>
> Is there a specific FQDN that NGINX is supposed to have?
>
> Thanks.
>
>
>
> --
> Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Re: Securing NiFI behind a proxy (NGINX).
Posted by scotty <yt...@msn.com>.
Hi Vijay,
After realizing that the reverse proxy was the problem, I've got NiFi,
standalone, secured with certificates by removing the reverse proxy out of
the mix.
Is there some example, somewhere, of using a NGINX reverse proxy so that I
can have the following setup?
client > https > NGINX > https > NiFi
My understanding is that NGINX needs a client certificate and that the FQDN
of that certificate needs to be setup to proxy user requests in the NiFi UI.
I've done both of these things as well as setup the nifi.web.proxy.host and
nifi.web.proxy.context.path in the nifi.properties file.
Is there a specific FQDN that NGINX is supposed to have?
Thanks.
--
Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Re: Securing NiFI behind a proxy (NGINX).
Posted by Vijay Chhipa <vc...@apple.com>.
Scotty,
When you turn an unsecured cluster to secured one, authentication is turned on.
You have to configure one of the authentication mechanism (Kerberos, LDAP, OIDC, ClientCertificates) in your nifi.properties.
> On Sep 7, 2020, at 3:28 AM, scotty <yt...@msn.com> wrote:
>
> Hi,
>
> 1. I had an usecured NiFi setup running: "Client > https > reverse proxy >
> http > NiFi"
>
> 2. I tried to secure it using the instructions at
> https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit.
> Certificates were generate as follows:
>
> a. ./bin/tls-toolkit.sh standalone -n '<my domain name>'
>
> b. ./home/scotty/nifi-toolkit-1.9.1/bin/tls-toolkit.sh standalone -C
> 'CN=my_username,OU=NiFi'
>
> 3. added CN=my_username,OU=NiFi in authorizers.xml (users.xml and
> authorizations.xml appear correct)
>
> 4. The response I'm getting at the NiFI URL is 'Insufficient Permissions:
> Unknown user with identity 'CN=localhost, OU=NIFI'. Contact the system
> administrator.'
>
> 5. I'm getting the same message from whatever computer I try to access the
> UI from, whether it has the user certificate installed or not. So who's
> making the request to authenticate?
>
> 6. nifi-user.log shows as follows:
>
> INFO [NiFi Web Server-84] o.a.n.w.s.NiFiAuthenticationFilter Attempting
> request for (CN=localhost, OU=NIFI) GET https://<my domain
> name>/nifi-api/flow/current-user (source ip: <ip address>)
>
> 2020-08-30 15:43:45,820 INFO [NiFi Web Server-84]
> o.a.n.w.s.NiFiAuthenticationFilter
> Authentication success for CN=localhost, OU=NIFI
>
> 2020-08-30 15:43:45,831 INFO [NiFi Web Server-84]
> o.a.n.w.a.c.AccessDeniedExceptionMapper identity[CN=localhost, OU=NIFI],
> groups [] does not have permission to access the requested resource. Unknown
> user with identity 'CN=localhost, OU=NIFI'. Returning Forbidden response
>
> 7. My NiFI truststore.jks shows the following:
>
> keystore contains 1 entry
> Alias name: nifi-cert
> Entry type: trustedCertEntry
> Owner: CN=localhost, OU=NIFI
> Issuer: CN=localhost, OU=NIFI
>
>
> 8. When I tried to use the X-ProxiedEntitiesChain header in my NGINX config,
> I got an "untrusted proxy" error when trying to access the NiFI UI.
>
> Was I suppsed to secure NiFi without the reverse proxy and then setup the
> proxy through the NiFI UI (as discussed in the following)?
>
> "If NiFi is running securely, any proxy needs to be authorized to proxy user
> requests. These can be configured in the NiFi UI through the Global Menu.
> Once these permissions are in place, proxies can begin proxying user
> requests. The end user identity must be relayed in a HTTP header. For
> example, if the end user sent a request to the proxy, the proxy must
> authenticate the user. Following this the proxy can send the request to
> NiFi. In this request an HTTP header should be added as follows."
>
>
> 9. Was I supposed to generate a certificate for the proxy (as discussed in
> this Apache Knox tutorial)?
> https://risdenk.github.io/2018/03/18/apache-knox-proxying-apache-nifi.html
>
>
> Any guiidance appreciated.
>
> Thanks.
>
>
>
>
>
>
>
>
>
> --
> Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/