generating authorizations on initial startup
When starting NiFi for the first time using the managed-authorizer, NiFi will put the Initial Admin Identity in certain Access Policies. However, it only does this for Global Access Policies, and does not add this user to any Component Access Policies, e.g. 'view/modify the component'. This has been frustrating, but as I understand it is unavoidable because the UUID of the root process group has not yet been created (there is no flow.xml.gz) at the time the policies are generated. However, I found that if a flow.xml.gz existed without a corresponding authorizations.xml or users.xml, then the startup process would in fact create the Component Access Policies and add the admin user to them. Now, with the introduction of flow.json.gz, the root process group has both "identifier" and "instanceIdentifier" properties. The Component Access Policies created on startup as described above reference the "identifier" UUID, but the UI indicates the "instanceIdentifier" is the proper UUID for the root process group. Therefore, the Component Access Policies are ineffective as they reference an incorrect UUID value. Is generating the Component Access Policies in this way supported? If so, then I will submit a ticket for using the proper UUID value when creating the policies. Thanks, Mark
Re: generating authorizations on initial startup
I think you are right, it looks like in FlowParser parseJson, the returned FlowInfo comes from this... final VersionedProcessGroup rootGroup = dataflow.getRootGroup(); return new FlowInfo(rootGroup.getIdentifier(), ports); Which I think should be the instance identifier there. On Wed, Jul 13, 2022 at 11:57 AM Mark Bean wrote: > > When starting NiFi for the first time using the managed-authorizer, NiFi > will put the Initial Admin Identity in certain Access Policies. However, it > only does this for Global Access Policies, and does not add this user to > any Component Access Policies, e.g. 'view/modify the component'. > > This has been frustrating, but as I understand it is unavoidable because > the UUID of the root process group has not yet been created (there is no > flow.xml.gz) at the time the policies are generated. > > However, I found that if a flow.xml.gz existed without a corresponding > authorizations.xml or users.xml, then the startup process would in fact > create the Component Access Policies and add the admin user to them. > > Now, with the introduction of flow.json.gz, the root process group has > both "identifier" and "instanceIdentifier" properties. The Component > Access Policies created on startup as described above reference the > "identifier" UUID, but the UI indicates the "instanceIdentifier" is the > proper UUID for the root process group. Therefore, the Component Access > Policies are ineffective as they reference an incorrect UUID value. > > Is generating the Component Access Policies in this way supported? > > If so, then I will submit a ticket for using the proper UUID value when > creating the policies. > > Thanks, > Mark
Re: generating authorizations on initial startup
Thanks for confirming Bryan. I created a ticket for this issue: https://issues.apache.org/jira/browse/NIFI-10228 On Wed, Jul 13, 2022 at 12:08 PM Bryan Bende wrote: > I think you are right, it looks like in FlowParser parseJson, the > returned FlowInfo comes from this... > > final VersionedProcessGroup rootGroup = dataflow.getRootGroup(); > return new FlowInfo(rootGroup.getIdentifier(), ports); > > Which I think should be the instance identifier there. > > On Wed, Jul 13, 2022 at 11:57 AM Mark Bean wrote: > > > > When starting NiFi for the first time using the managed-authorizer, NiFi > > will put the Initial Admin Identity in certain Access Policies. However, > it > > only does this for Global Access Policies, and does not add this user to > > any Component Access Policies, e.g. 'view/modify the component'. > > > > This has been frustrating, but as I understand it is unavoidable because > > the UUID of the root process group has not yet been created (there is no > > flow.xml.gz) at the time the policies are generated. > > > > However, I found that if a flow.xml.gz existed without a corresponding > > authorizations.xml or users.xml, then the startup process would in fact > > create the Component Access Policies and add the admin user to them. > > > > Now, with the introduction of flow.json.gz, the root process group has > > both "identifier" and "instanceIdentifier" properties. The Component > > Access Policies created on startup as described above reference the > > "identifier" UUID, but the UI indicates the "instanceIdentifier" is the > > proper UUID for the root process group. Therefore, the Component Access > > Policies are ineffective as they reference an incorrect UUID value. > > > > Is generating the Component Access Policies in this way supported? > > > > If so, then I will submit a ticket for using the proper UUID value when > > creating the policies. > > > > Thanks, > > Mark >
Re: Jira contributor access
Kirill, I have added you as a contributor to the Apache NiFi Jira projects. Looking forward to your contributions! Regards, Matt On Mon, Jul 11, 2022 at 2:11 AM Kirill Morozov wrote: > > Hi, > could anyone help me with this ? > > Thank you! > > чт, 7 июл. 2022 г. в 16:05, Kirill Morozov : > > > Hello, > > please give me Jira contributor access > > > > My jira username: kmor > > > > Thank you! > >
