Support Questions

Find answers, ask questions, and share your expertise

NiFi login redirect issue: 'Success - You are already logged in'

avatar
Contributor

I have configured kerberos authentication, with file backed authorize.

NiFi is using SSL with signed certificates from a windows domain CA, with the relevant DN's added to Node Identities.

I can login, and authenticate successfully, but I seem to hit a strange redirect loop on login. I simply endlessly redirect to:

Success You are already logged in.

With 'log out' and 'home' buttons available. If I hit home I am redirected to the same message. Despite what it's telling me it doesn't feel very successful!

Any ideas?

Cheers

EDIT:

A bit more info: I have a cluster of two nodes. If I authenticate to node1 my node1 nifi-user.log will show success messages, node2 will throw an error:

ERROR [NiFi Web Server-16] o.a.nifi.web.security.jwt.JwtService There was an error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the access token.

... Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted.

Like wise if I authenticate on node2, node1 will show this error.

1 ACCEPTED SOLUTION

avatar
Master Mentor
@Oliver Fletcher

When you login into the UI for a specific node in your cluster a token is returned which can be used to continue access that nodes UI only until the token expires (default is 12 hours). That token cannot be used to access the UI of any other node. Each node would need its own token. With a NiFi cluster any changes you make within the UI are propagated to all nodes in the cluster. So I am not sure i understand the need to use the same token to access the UI on each node.

Thanks,

Matt

View solution in original post

5 REPLIES 5

avatar
Master Mentor
@Oliver Fletcher

When you login into the UI for a specific node in your cluster a token is returned which can be used to continue access that nodes UI only until the token expires (default is 12 hours). That token cannot be used to access the UI of any other node. Each node would need its own token. With a NiFi cluster any changes you make within the UI are propagated to all nodes in the cluster. So I am not sure i understand the need to use the same token to access the UI on each node.

Thanks,

Matt

avatar
Contributor

@Matt

I was a bit unclear. If I attempt to authorise myself to the UI of node1 in my cluster, node2 will throw that error at that moment. The logs in node1 will show a successful authentication.

Node 1 will then just happily redirect me to a generic success message page, which I can't progress pass.

EDIT CLUE 2: If I regenerate self signed certs (not my signed certs) using the NIFA CA then login this message goes away!

avatar
Master Mentor

@Oliver Fletcher

Your issue seems more tied to your self-signed server certs. You need to have a keystore and a truststore on each of your nodes.

KEYSTORE:

The keystore will contain a "PrivateKeyEntry" for the server on which it is being used. This certificate is either self-signed or signed by a CA. For NiFi, this certificate must be created so that it can be used for both ClientAuth and ServerAuth. Nodes in a NiFi cluster can act as both a server or a client at times. (Communicating from node 1 (clientAuth) to node 2 (ServerAuth) for example where node 1 is acting as a client). Often times I see server certificates created for serverAuth only. While that is all that is needed for a user to access the UI, it will cause issues when the node needs to act as a client (Node to Node communication and NiFi's S2S capability). If when communicating from node 1 to node 2 (assuming node 1's cert is server Auth only, the request to node 2 will not contain a server cert since node 1 is acting as the client) node 2 will end up reading the token in the header since the server certificate was not provided. This would explain the behavior you are seeing.

TRUSTSTORE:

This file is not unique on each node. It will contain 1 or more trustedCertEntries. Those TrustedCertEntries will can be for various CAs or for each self-signed cert it should trust. In you case with a 2 node cluster, the truststore must contain the trustedCertEntry for each of your nodes certificates. The same truststore would then be used on all the nodes.

Here is a link to an article that covers creating keystores and truststores for use in a NiFi cluster:

https://community.hortonworks.com/articles/17293/how-to-create-user-generated-keys-for-securing-nif....

Thanks,

Matt

avatar
New Contributor

Hey @Matt Clarke,

Thanks for great information.

However, we cannot call it a cluster because it's not a cluster in frontend... token is not shared as You said.

What if I have a loadbalancer in front and it forwards traffic to one or another member of the cluster? My authentication breaks exactly in this scenario. And I run all this stuff in Cloud environment, and this loadbalancer for example does not support something like session persistence. Would it be hard to implement this feature for token to be shared?

Thanks!

avatar
Master Mentor
@Johny Travolta

I don't understand how not having a shared token necessarily means you do not have a cluster. You will get better traction form the community if you move this to a new question. I am not a NiFi developer myself, so I could not comment on the complexity of implementing a shared LDAP token response across all nodes in a NiFi cluster. But I am sure if you open a new question around this topic, you will get a response from someone who can answer for you.

Thanks,

Matt