I remember trying to solve this a long time ago during the 1.0.0 development when the new authorizer API was implemented, but I honestly can't remember all the issues. A lot of stuff has changed since so maybe a fresh look is worth it.
StandardFlowService already has a member variable with the Authorizer, you can see examples of where it uses it. If its a ManagedAuthorizer then you can get access to the policy provider and see if its a configurable one. The only issue I see with this approach is that its putting the decision to seed the policies into the framework, where as for the other policies it is a decision of the policy provider so it is done inside the file-based provider. Not sure if this is really an issue, but we just need to consider all the scenarios. On Wed, Apr 3, 2019 at 4:44 PM Mark Bean <mark.o.b...@gmail.com> wrote: > > Bryan, > > Ok, thanks. Now, the issue is when there is no flow established yet. In > that case, FileAccessPolicyProvider.populateInitialAdmin will not find the > rootGroupId; it doesn't exist yet in cases where there is no flow.xml.gz on > startup. So, component access policies cannot be created. > > The flow.xml.gz is initially created in StandardFlowService.load(DataFlow). > Here, the rootGroupId is known (or can be derived from the controller.) > However, at this point, there is no access to the FileAccessPolicyProvider > which is required to updated the policies. Hence, the problem of not > completing the authorizations (i.e. component policies) for an Initial > Admin User. > > Do you have suggestions on how to access the FileAccessPolicyProvider (or > more generally a ConfigurableAccessPolicyProvider)? > > Thanks again, > Mark > > > > On Tue, Apr 2, 2019 at 10:35 PM Bryan Bende <bbe...@gmail.com> wrote: > > > The initial admin policies are created here: > > > > > > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/FileAccessPolicyProvider.java#L595 > > < > > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/FileAccessPolicyProvider.java#L595 > > > > > > > You can see where it will create the root group policies if rootGroupId is > > not null. > > > > The rootGroupId comes from the parseFlow() method above which tries to > > read the flow.xml.gz from disk, using the location from nifi.properties. > > > > > > > On Apr 2, 2019, at 9:57 PM, Mark Bean <mark.o.b...@gmail.com> wrote: > > > > > > When NiFi is started for the first time, the Component Access Policies > > are > > > not populated even for the Initial Admin or for legacy DFM_ROLE users in > > > authorized-users.xml file.That is, not unless a flow.xml.gz file exists. > > > The fact that the admin user does not have access to these policies has > > led > > > to confusion for a great number of users. > > > > > > I believe this came up before and an explanation was given that since the > > > flow.xml.gz does not yet exist (nor the root process group's UUID), the > > > Component Access Policies cannot be created. However, I have to believe > > > there is a mechanism that can be employed to return to policy generation > > > after the flow.xml.gz is created. > > > > > > Can someone provide some pointers to where in the code I can look to see > > > where the Global Policies are initially created and/or where Component > > > Policies are created when migrating with an existing flow.xml.gz? > > > > > > Thanks, > > > Mark > > > >
