Skip to main content
yoonli
Silver ⭐️⭐️⭐️
September 8, 2025
Question

Config nifi behind haproxy

I want to config haproxy as LB for nifi web. My nifi cluster is configured using self certificate. When accessing to nifi web, I got the error user unauthorization. Here is my config:

global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/stats

defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
timeout http-request 10s
timeout http-keep-alive 10

frontend nifi
bind *:80
mode http
default_backend nifi
http-request set-header X-ProxyScheme http
http-request set-header X-ProxyHost %[hdr(host)]
http-request set-header X-ProxyPort 80
http-request set-header X-Forwarded-For %[src]
http-request set-header X-Forwarded-Proto http

backend nifi
mode http
server nifi01 10.29.144.56:8443 ssl verify none
server nifi02 10.29.144.57:8443 ssl verify none
server nifi03 10.29.144.58:8443 ssl verify none
nifi.web.proxy.host=10.29.144.56

 

1 reply

MattWho
Titanium ⭐️⭐️⭐️
Titanium ⭐️⭐️⭐️
September 8, 2025

@yoonli 

It would be helpful if you shared the complete authorization exception you are encountering.  I have a feeling your authorization exception is not related to your server certificate, but more related to your individual NiFi user.

Using a load balancer in front of your NiFi cluster would require that session affinity (sticky sessions) is enabled in your load balancer. 
The why?

  • Any login based user authentication (ldap-provider, kerberos-provdier, etc) result in a token being issued to the user and a server side token stored on the NiFi server that issues the client token. Only the specific node in the NiFi cluster that issued the client bearer token will have the corresponding server side token.
  • If your load balancer does not have sticky sessions enabled subsequent requests after obtaining the client bearer token may get direct to a different node in the cluster.
  • Your browser will include this client token in all subsequent request to NiFi
  • Since the other nodes will not hav the corresponding server token for your user the session would result in an not authorized response. 

Possible helpful HAProxy links:

----

Certificate based authentication is not an issue since the client/server MutualTLS exchange happens in every communication between client and server.   This is why is suspect that your setup involves a login based authentication method.

----

I see you configured your LB IP in the nifi.web.proxy.host property within the nifi.properties file.   This property has nothing directly related to client/user authentication.  It is about making sure NiFi accepts requests destined for a different hostname/IP then the destination host that received it. Let's say you initiate a connection to URL containing host: https://10.29.144.56/nifi/ 

Your HAProxy then routes that request to NiFi on host 10.29.144.58 which returns a server certificate with that servers hostname or the IP 10.29.144.58.  The connection is going to be blocked because it appears as a man-in-the-middle attack.  The expectation was that the request would be processed by the server 10.29.144.56; however, host 10.29.144.58 received the request.  By adding 10.29.144.56 to the proxy.host property in NiFi, you are telling NiFi to accept requests intended for a different hostname or IP then the actual NiFi's hostname or IP.

 

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

 

Translate