Created 05-15-2022 10:05 PM
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?
Created 05-16-2022 08:31 AM
@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
Created 05-16-2022 06:55 AM
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
Created 05-16-2022 08:31 AM
@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
Created on 05-17-2022 07:54 PM - edited 05-17-2022 07:56 PM