Support Questions

Find answers, ask questions, and share your expertise

Nifi authentication fails when a HTTPS load balancer is used

avatar
New Contributor

Hi, I am new to Nifi, so please excuse if this is a noob question.

 

I have set up a 5 node Nifi cluster on GCP and using LDAP for authentication. I generated self-signed certs using the toolkit and I am able to login and access the UI at https://<hostname>:8443/nifi/. Everything looks good with this setup.

 

Now, I added a HTTPS load balancer that routes the requests to backend Nifi nodes, when I try to access the Nifi UI at https://<load-balancer>/nifi/ it throws below error

 

 INFO [NiFi Web Server-251] o.a.n.w.s.NiFiAuthenticationFilter Authentication Started xx.xx.xxx.x [<anonymous>] GET https://nifi.xxxxx.com/nifi-api/flow/current-user

WARN [NiFi Web Server-251] o.a.n.w.s.NiFiAuthenticationFilter Authentication Failed xx.xx.xxx.x GET https://nifi.xxxxx.com/nifi-api/flow/current-user [Anonymous authentication has not been configured.]

 

I generated the certificate using below command

 

./tls-toolkit.sh standalone -n 'nifixxxxxx[1-5].xxxx.com' -S 'xxxxxxx' -P 'xxxxxxx' -C 'CN=<ldap-userid>, OU=NIFI'

 

 Can someone help me understand why the user id shows as anonymous and how to fix it?

1 ACCEPTED SOLUTION

avatar
Master Mentor

@bk1937 

I 100% agree with the advice given by @ckumar 

Also consider for a basic LB setup, you'll need to use sticky sessions.
You mention that you are "logging in", so I take this to mean that your user(s) are not using certificate based authentication, but rather using a login provider like ldap-provider or kerberos-provider.

When you access "https://<load-balancer>/nifi/ " without using sticky sessions, the request may go to node 1 where you get the login window.  You enter your credentials and get back a bearer token that your browser now stores for the "https://<load-balancer>/nifi/ " endpoint.   The issue here is that bearer token is only valid for the host that issued it (node1).  So immediately after node1 sent your browser this token, it attempts to redirect your browser to UI.  Without Sticky Sessions, your LB may send the redirect to node 2 - 5) and those nodes will not know anything about that client bearer token since they will not have the corresponding server side token.  This the token is rejected and your user is treated as anonymous.

You'll need to investigate your LB to see how to enable sticky sessions.  Sticky sessions will make sure all subsequent request continue to get routed to same host as original request.

If you any of the responses assisted with your query, please take a moment to login and click on "Accept as Solution" below each of those posts.

Thank you,

Matt




View solution in original post

3 REPLIES 3

avatar
Master Collaborator

With LB in place, you are reaching NiFi as anonymous when LB has not been configured to pass the user identity to NiFi that what I understand from looking the log snippet.. Please refer this page to check if proxy details are configured correctly  https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#proxy_configuration

avatar
Master Mentor

@bk1937 

I 100% agree with the advice given by @ckumar 

Also consider for a basic LB setup, you'll need to use sticky sessions.
You mention that you are "logging in", so I take this to mean that your user(s) are not using certificate based authentication, but rather using a login provider like ldap-provider or kerberos-provider.

When you access "https://<load-balancer>/nifi/ " without using sticky sessions, the request may go to node 1 where you get the login window.  You enter your credentials and get back a bearer token that your browser now stores for the "https://<load-balancer>/nifi/ " endpoint.   The issue here is that bearer token is only valid for the host that issued it (node1).  So immediately after node1 sent your browser this token, it attempts to redirect your browser to UI.  Without Sticky Sessions, your LB may send the redirect to node 2 - 5) and those nodes will not know anything about that client bearer token since they will not have the corresponding server side token.  This the token is rejected and your user is treated as anonymous.

You'll need to investigate your LB to see how to enable sticky sessions.  Sticky sessions will make sure all subsequent request continue to get routed to same host as original request.

If you any of the responses assisted with your query, please take a moment to login and click on "Accept as Solution" below each of those posts.

Thank you,

Matt




avatar
New Contributor

Thanks @ckumar @MattWho for your responses.
I enabled session affinity on LB and it resolved the issue. I am able to login using LB endpoint. 
What @ckumar said makes sense but why isn't it causing any issue for my cluster? Is it because I am using just basic LB and not Reverse proxy?