How to achieve true multi tenancy in nifi?

[#1]

I have setup user authentication using ldap for nifi. Now when Iam able to add new users and achieve access restrictions to different users etc. But still now Iam not able to understand how to truly achieve multi-tenancy with nifi. For eg. when I add new users and to let them view the interface I give the policy to view the interface. But the user is still able to see all the components positions and connections even though not able to access them. This is not true multi-tenancy as I understand because users should not be able to see things even though not accessible to them. The same is problem with the controllers. Users are able to view them but not access or edit. It is also not possible to create a admin just for a tenant. Is there anyway we can truly achieve this in nifi?

@MattWho  @bbende  @pam1 

[#2]

Assuming you are using File based default Authoriser in NIFI, and if you are managing policies  from Top right Hamburger menu, there you see default policy and do not get an option to create polices specific to Process Group or Processor level. So you need to use Operate tile "key" icon to configure granular policies. 

For example I have process group name test and when select this process group I get Operate controls of PG test and when user click on key icon 

 

This is page where user  lands in were , user has an option to add/remove users for specific policies  by using Override option 

in this example user : nifiadmin which earlier had view the component ,   removed from list and then we will see  how it looks like for user nifiadmin the PG test on UI. 

 

 

Hope this helps.

Thank You.

[#3]

@pacman 

In addition to what @ckumar already shared:

NiFI purposely leaves components visible to all on the canvas. but unless authorized to view those components, they will display as "ghost" implementations.   "Ghosted" components will not show any component names or classes on them.  They will only show stats.  Unauthorized users will be unable to view or modify the configuration.  User will also be unable to list or view data in connections (only see numbers of FlowFiles queued on a connection).

The reason NiFi shows these ghosted components is to prevent multiple users from building their dataflows on top of one another.  It is very common for users to have multiple teams building their own dataflows, but then also have monitoring teams that may be authorized as "operators" across all dataflows.
Or they may have some users that are members of multiple teams.   That means these users who can see more, would be left with potentially components layered on top of one another making management very difficult.

The stats are there so even if a user can not view or modify a component, they can see where FlowFile backlogs are happening.  Since NiFi operates within a single JVM and every dataflow, no matter which user/team built them, is executed as the NiFi service user, everything must share the same system resources (various repos, Heap memory, disk  I/O, cpu, etc).   These stats provide useful information that one team can use to communicate to another team should resource utilization become an issue.

NiFi's authorization model allows users to make very granular access decisions for every component.  Authorizations are inherited from the parent process group unless more granular policies are setup on a child component (processor, controller service, input/output port, sub-process group, etc..). 

Hope this helps,
Matt