Preserve identity in multi-tenant NiFi over site-to-site?

[#1]

I have a "client" NiFi instance that has multiple tenants, and each of those tenants wish to use site-to-site communication to a NiFi cluster over SSL. The cluster can assign privileges to the incoming client connection based on the client cert (eg a cluster user matching 'CN=client.local, OU=NIFI'), but I don't see a way of differentiating between the client tenants on the cluster side. Ideally I'd say UserA from the client can only access InputPortA on the cluster but not InputPortB, even though UserB from the client side can access InputPortB. It seems like all client tenant identities get squashed down to the CN of the client cert. Is there a way to keep one identity distinct throughout the chain? Would multiple SANs (Subject Alternative Name) in the client NiFi cert help here?

Thanks!

[#2 · Accepted solution]

@Oliver Meyn

You are correct that the Site-To-Site connection and authorizations is handled at the server level and not at the user level. There is no configuration change you can make that would change this behavior. The authorization level is allowing server A to communicate and send data to serverB. Users play no role in the S2S data transfer process. I am not sure how this enhancement would work. Setting the authorization level of S2S down to the user level would require adding these users to serverB which may not be desirable. Also what if ServerA has a process group with the RPG that is authorized by many users? Would the expectation be that every on of those users then needs to be added/authorized to serverB? I suggest opening an apache Jira against NiFi to raise additional discussion around this topic.

Thanks,

Matt

[#3]

Also wanted to mention that site-to-site can only happen with ports on the root canvas, which is done intentionally to make it clear that it is a system decision to send or receive data out of the given instance. This means that the user that sets up the port would need write access to the root canvas, which typically in a multi-tenant environment tenants would be given to a sub-process group, but they would still need some other administrator to setup the site-to-site connection for them.