You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Lars Francke <la...@gmail.com> on 2018/11/08 16:31:52 UTC
API to get all Policies
Hi,
I was tasked with writing a tool to generate a kind of "audit report". For
that I need to get all policies that people have across various systems.
NiFi is one of them.
I see that we have a REST API for Policies but that doesn't expose a method
to expose _all_ policies. I'd like to add a REST endpoint that allows
retrieving all policies.
Before I open a Jira I wanted to get feedback whether this addition would
be acceptable.
Implementation notes
This is how I see the current flow of requests from the
AccessPolicyResource to the actual AccessPolicyProider:
AccessPolicyResource -> NiFiServiceFacade (StandardNiFiServiceFacade) ->
AccessPolicyDAO (StandardPolicyBasedAuthorizerDAO) -> AccessPolicyProvider
Fortunately the AccessPolicyProvider already has a method to retrieve all
policies. Should there be custom implementations by third-parties they
already support the necessary methods and I believe the classes that need
to be changed are all NiFi internal:
* AccessPolicyResource
* NiFiServiceFacade
* StandardNiFiServiceFacade
* AccessPolicyDAO
* StandardPolicyBasedAuthorizerDAO
* And probably a bunch of others especially test classes
If I don't hear any objections I will open a Jira issue and would try and
provide a patch.
Cheers,
Lars
Re: API to get all Policies
Posted by Kevin Doran <kd...@gmail.com>.
Sounds good to me. Thanks, Lars. If/when you open a PR feel free to ping me for a review.
On 11/27/18, 13:55, "Lars Francke" <la...@gmail.com> wrote:
Kevin,
thank you for your answer and sorry for the long delay.
I agree that paging is a concern and I thought about it as well but I also
agree that in this case it's probably not worth the hassle.
I'll go ahead and create a Jira. I plan on providing a patch but not sure
when I'll get to it.
Cheers,
Lars
On Fri, Nov 9, 2018 at 6:38 PM Kevin Doran <kd...@gmail.com> wrote:
> Hi Lars,
>
> I think as long as the following are true (it sounds like they are from
> what you have looked at):
>
> 1. the proposed endpoint does not require adding any additional
> Authorizable or policy to protect, and
> 2. the proposed endpoint does not expose any information that the
> authenticated client/user would not already have access to view, and is
> merely acting as a convenience method to return a list of things they could
> fetch individually
>
> then in that case this is probably fine. No objection from me.
>
> Any time we are adding a collection endpoint, my main concern is if
> pagination of the results also needs to be added (i.e., if for typical
> usage of NiFi, the response size of the JSON result would be larger than is
> reasonable to transmit in a single HTTP round trip, or if creating the
> response would be unreasonable load on the server). In typical usage of
> NiFi, I don't think the number of policies is that large (perhaps others
> can chime in if they feel differently?), so it would come down to what is
> the size of a policy element when returned in a list. If it is very large,
> you may also want to introduce a summary view/perspective of the policy
> that reduces the amount of information to the minimal that is required for
> a list view... I think that may already exist for NiFi in the
> AccessPolicySummary object, but it's been a while since I've looked at the
> code so I may be forgetting the details or confusing it with the NiFi
> Registry implementation, which does have a get all policies endpoint.
>
> Lastly, take care that the Swagger annotations that are used to drive the
> Rest API documentation are accurate. If you have any questions on that let
> me know. Happy to help review a PR if you submit one.
>
> Regards,
> Kevin
>
> On 11/9/18, 06:23, "Lars Francke" <la...@gmail.com> wrote:
>
> I've just tried implementing my new resource and it seems to work fine
> and
> as I expect it to. Also in regards to authorization. Users cannot see
> anything that they are not allowed to do anyway.
>
> Regarding your other comments: I agree that it's probably not a super
> common use case.
>
> Either way I'd love to use a API that I can access remotely as I need
> to
> connect to other systems as well (e.g. Kafka, HBase etc.) so I don't
> want
> to colocate my service on one of the NiFi machines.
> But yes I could probably get a list of all resources somehow using the
> API
> and then send one request per resource. But that seems overly
> complicated.
>
> So if you don't object I'd create a Jira.
>
> Cheers,
> Lars
>
>
> On Fri, Nov 9, 2018 at 10:01 AM Lars Francke <la...@gmail.com>
> wrote:
>
> > Andy,
> >
> > that's a good question. I have to admit that I thought about it and
> then
> > saw that there is already an Authorizable for this scenario so I
> assumed
> > that part was already taken care of. So whoever has the permission
> to view
> > "access all policies" would also be able to use the API? Were you
> thinking
> > of something different?
> >
> > Cheers,
> > Lars
> >
> >
> >
> > On Fri, Nov 9, 2018 at 12:35 AM Andy LoPresto <al...@apache.org>
> > wrote:
> >
> >> Lars,
> >>
> >> What access controls do you anticipate putting on this API endpoint
> and
> >> what potential issues do you see? I could see this being abused if
> not
> >> secured very carefully, and it doesn’t seem like a common use case
> >> (notwithstanding your current requirement). Is this something that
> can be
> >> done by using the NiFi CLI to iterate/recurse through the various
> PGs and
> >> retrieve these policies?
> >>
> >> Andy LoPresto
> >> alopresto@apache.org
> >> alopresto.apache@gmail.com
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >>
> >> > On Nov 9, 2018, at 3:31 AM, Lars Francke <la...@gmail.com>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I was tasked with writing a tool to generate a kind of "audit
> report".
> >> For
> >> > that I need to get all policies that people have across various
> systems.
> >> > NiFi is one of them.
> >> >
> >> > I see that we have a REST API for Policies but that doesn't
> expose a
> >> method
> >> > to expose _all_ policies. I'd like to add a REST endpoint that
> allows
> >> > retrieving all policies.
> >> > Before I open a Jira I wanted to get feedback whether this
> addition
> >> would
> >> > be acceptable.
> >> >
> >> > Implementation notes
> >> > This is how I see the current flow of requests from the
> >> > AccessPolicyResource to the actual AccessPolicyProider:
> >> >
> >> > AccessPolicyResource -> NiFiServiceFacade
> (StandardNiFiServiceFacade) ->
> >> > AccessPolicyDAO (StandardPolicyBasedAuthorizerDAO) ->
> >> AccessPolicyProvider
> >> >
> >> > Fortunately the AccessPolicyProvider already has a method to
> retrieve
> >> all
> >> > policies. Should there be custom implementations by third-parties
> they
> >> > already support the necessary methods and I believe the classes
> that
> >> need
> >> > to be changed are all NiFi internal:
> >> >
> >> > * AccessPolicyResource
> >> > * NiFiServiceFacade
> >> > * StandardNiFiServiceFacade
> >> > * AccessPolicyDAO
> >> > * StandardPolicyBasedAuthorizerDAO
> >> > * And probably a bunch of others especially test classes
> >> >
> >> > If I don't hear any objections I will open a Jira issue and would
> try
> >> and
> >> > provide a patch.
> >> >
> >> > Cheers,
> >> > Lars
> >>
> >>
>
>
Re: API to get all Policies
Posted by Lars Francke <la...@gmail.com>.
Kevin,
thank you for your answer and sorry for the long delay.
I agree that paging is a concern and I thought about it as well but I also
agree that in this case it's probably not worth the hassle.
I'll go ahead and create a Jira. I plan on providing a patch but not sure
when I'll get to it.
Cheers,
Lars
On Fri, Nov 9, 2018 at 6:38 PM Kevin Doran <kd...@gmail.com> wrote:
> Hi Lars,
>
> I think as long as the following are true (it sounds like they are from
> what you have looked at):
>
> 1. the proposed endpoint does not require adding any additional
> Authorizable or policy to protect, and
> 2. the proposed endpoint does not expose any information that the
> authenticated client/user would not already have access to view, and is
> merely acting as a convenience method to return a list of things they could
> fetch individually
>
> then in that case this is probably fine. No objection from me.
>
> Any time we are adding a collection endpoint, my main concern is if
> pagination of the results also needs to be added (i.e., if for typical
> usage of NiFi, the response size of the JSON result would be larger than is
> reasonable to transmit in a single HTTP round trip, or if creating the
> response would be unreasonable load on the server). In typical usage of
> NiFi, I don't think the number of policies is that large (perhaps others
> can chime in if they feel differently?), so it would come down to what is
> the size of a policy element when returned in a list. If it is very large,
> you may also want to introduce a summary view/perspective of the policy
> that reduces the amount of information to the minimal that is required for
> a list view... I think that may already exist for NiFi in the
> AccessPolicySummary object, but it's been a while since I've looked at the
> code so I may be forgetting the details or confusing it with the NiFi
> Registry implementation, which does have a get all policies endpoint.
>
> Lastly, take care that the Swagger annotations that are used to drive the
> Rest API documentation are accurate. If you have any questions on that let
> me know. Happy to help review a PR if you submit one.
>
> Regards,
> Kevin
>
> On 11/9/18, 06:23, "Lars Francke" <la...@gmail.com> wrote:
>
> I've just tried implementing my new resource and it seems to work fine
> and
> as I expect it to. Also in regards to authorization. Users cannot see
> anything that they are not allowed to do anyway.
>
> Regarding your other comments: I agree that it's probably not a super
> common use case.
>
> Either way I'd love to use a API that I can access remotely as I need
> to
> connect to other systems as well (e.g. Kafka, HBase etc.) so I don't
> want
> to colocate my service on one of the NiFi machines.
> But yes I could probably get a list of all resources somehow using the
> API
> and then send one request per resource. But that seems overly
> complicated.
>
> So if you don't object I'd create a Jira.
>
> Cheers,
> Lars
>
>
> On Fri, Nov 9, 2018 at 10:01 AM Lars Francke <la...@gmail.com>
> wrote:
>
> > Andy,
> >
> > that's a good question. I have to admit that I thought about it and
> then
> > saw that there is already an Authorizable for this scenario so I
> assumed
> > that part was already taken care of. So whoever has the permission
> to view
> > "access all policies" would also be able to use the API? Were you
> thinking
> > of something different?
> >
> > Cheers,
> > Lars
> >
> >
> >
> > On Fri, Nov 9, 2018 at 12:35 AM Andy LoPresto <al...@apache.org>
> > wrote:
> >
> >> Lars,
> >>
> >> What access controls do you anticipate putting on this API endpoint
> and
> >> what potential issues do you see? I could see this being abused if
> not
> >> secured very carefully, and it doesn’t seem like a common use case
> >> (notwithstanding your current requirement). Is this something that
> can be
> >> done by using the NiFi CLI to iterate/recurse through the various
> PGs and
> >> retrieve these policies?
> >>
> >> Andy LoPresto
> >> alopresto@apache.org
> >> alopresto.apache@gmail.com
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >>
> >> > On Nov 9, 2018, at 3:31 AM, Lars Francke <la...@gmail.com>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I was tasked with writing a tool to generate a kind of "audit
> report".
> >> For
> >> > that I need to get all policies that people have across various
> systems.
> >> > NiFi is one of them.
> >> >
> >> > I see that we have a REST API for Policies but that doesn't
> expose a
> >> method
> >> > to expose _all_ policies. I'd like to add a REST endpoint that
> allows
> >> > retrieving all policies.
> >> > Before I open a Jira I wanted to get feedback whether this
> addition
> >> would
> >> > be acceptable.
> >> >
> >> > Implementation notes
> >> > This is how I see the current flow of requests from the
> >> > AccessPolicyResource to the actual AccessPolicyProider:
> >> >
> >> > AccessPolicyResource -> NiFiServiceFacade
> (StandardNiFiServiceFacade) ->
> >> > AccessPolicyDAO (StandardPolicyBasedAuthorizerDAO) ->
> >> AccessPolicyProvider
> >> >
> >> > Fortunately the AccessPolicyProvider already has a method to
> retrieve
> >> all
> >> > policies. Should there be custom implementations by third-parties
> they
> >> > already support the necessary methods and I believe the classes
> that
> >> need
> >> > to be changed are all NiFi internal:
> >> >
> >> > * AccessPolicyResource
> >> > * NiFiServiceFacade
> >> > * StandardNiFiServiceFacade
> >> > * AccessPolicyDAO
> >> > * StandardPolicyBasedAuthorizerDAO
> >> > * And probably a bunch of others especially test classes
> >> >
> >> > If I don't hear any objections I will open a Jira issue and would
> try
> >> and
> >> > provide a patch.
> >> >
> >> > Cheers,
> >> > Lars
> >>
> >>
>
>
Re: API to get all Policies
Posted by Kevin Doran <kd...@gmail.com>.
Hi Lars,
I think as long as the following are true (it sounds like they are from what you have looked at):
1. the proposed endpoint does not require adding any additional Authorizable or policy to protect, and
2. the proposed endpoint does not expose any information that the authenticated client/user would not already have access to view, and is merely acting as a convenience method to return a list of things they could fetch individually
then in that case this is probably fine. No objection from me.
Any time we are adding a collection endpoint, my main concern is if pagination of the results also needs to be added (i.e., if for typical usage of NiFi, the response size of the JSON result would be larger than is reasonable to transmit in a single HTTP round trip, or if creating the response would be unreasonable load on the server). In typical usage of NiFi, I don't think the number of policies is that large (perhaps others can chime in if they feel differently?), so it would come down to what is the size of a policy element when returned in a list. If it is very large, you may also want to introduce a summary view/perspective of the policy that reduces the amount of information to the minimal that is required for a list view... I think that may already exist for NiFi in the AccessPolicySummary object, but it's been a while since I've looked at the code so I may be forgetting the details or confusing it with the NiFi Registry implementation, which does have a get all policies endpoint.
Lastly, take care that the Swagger annotations that are used to drive the Rest API documentation are accurate. If you have any questions on that let me know. Happy to help review a PR if you submit one.
Regards,
Kevin
On 11/9/18, 06:23, "Lars Francke" <la...@gmail.com> wrote:
I've just tried implementing my new resource and it seems to work fine and
as I expect it to. Also in regards to authorization. Users cannot see
anything that they are not allowed to do anyway.
Regarding your other comments: I agree that it's probably not a super
common use case.
Either way I'd love to use a API that I can access remotely as I need to
connect to other systems as well (e.g. Kafka, HBase etc.) so I don't want
to colocate my service on one of the NiFi machines.
But yes I could probably get a list of all resources somehow using the API
and then send one request per resource. But that seems overly complicated.
So if you don't object I'd create a Jira.
Cheers,
Lars
On Fri, Nov 9, 2018 at 10:01 AM Lars Francke <la...@gmail.com> wrote:
> Andy,
>
> that's a good question. I have to admit that I thought about it and then
> saw that there is already an Authorizable for this scenario so I assumed
> that part was already taken care of. So whoever has the permission to view
> "access all policies" would also be able to use the API? Were you thinking
> of something different?
>
> Cheers,
> Lars
>
>
>
> On Fri, Nov 9, 2018 at 12:35 AM Andy LoPresto <al...@apache.org>
> wrote:
>
>> Lars,
>>
>> What access controls do you anticipate putting on this API endpoint and
>> what potential issues do you see? I could see this being abused if not
>> secured very carefully, and it doesn’t seem like a common use case
>> (notwithstanding your current requirement). Is this something that can be
>> done by using the NiFi CLI to iterate/recurse through the various PGs and
>> retrieve these policies?
>>
>> Andy LoPresto
>> alopresto@apache.org
>> alopresto.apache@gmail.com
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>
>> > On Nov 9, 2018, at 3:31 AM, Lars Francke <la...@gmail.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > I was tasked with writing a tool to generate a kind of "audit report".
>> For
>> > that I need to get all policies that people have across various systems.
>> > NiFi is one of them.
>> >
>> > I see that we have a REST API for Policies but that doesn't expose a
>> method
>> > to expose _all_ policies. I'd like to add a REST endpoint that allows
>> > retrieving all policies.
>> > Before I open a Jira I wanted to get feedback whether this addition
>> would
>> > be acceptable.
>> >
>> > Implementation notes
>> > This is how I see the current flow of requests from the
>> > AccessPolicyResource to the actual AccessPolicyProider:
>> >
>> > AccessPolicyResource -> NiFiServiceFacade (StandardNiFiServiceFacade) ->
>> > AccessPolicyDAO (StandardPolicyBasedAuthorizerDAO) ->
>> AccessPolicyProvider
>> >
>> > Fortunately the AccessPolicyProvider already has a method to retrieve
>> all
>> > policies. Should there be custom implementations by third-parties they
>> > already support the necessary methods and I believe the classes that
>> need
>> > to be changed are all NiFi internal:
>> >
>> > * AccessPolicyResource
>> > * NiFiServiceFacade
>> > * StandardNiFiServiceFacade
>> > * AccessPolicyDAO
>> > * StandardPolicyBasedAuthorizerDAO
>> > * And probably a bunch of others especially test classes
>> >
>> > If I don't hear any objections I will open a Jira issue and would try
>> and
>> > provide a patch.
>> >
>> > Cheers,
>> > Lars
>>
>>
Re: API to get all Policies
Posted by Lars Francke <la...@gmail.com>.
I've just tried implementing my new resource and it seems to work fine and
as I expect it to. Also in regards to authorization. Users cannot see
anything that they are not allowed to do anyway.
Regarding your other comments: I agree that it's probably not a super
common use case.
Either way I'd love to use a API that I can access remotely as I need to
connect to other systems as well (e.g. Kafka, HBase etc.) so I don't want
to colocate my service on one of the NiFi machines.
But yes I could probably get a list of all resources somehow using the API
and then send one request per resource. But that seems overly complicated.
So if you don't object I'd create a Jira.
Cheers,
Lars
On Fri, Nov 9, 2018 at 10:01 AM Lars Francke <la...@gmail.com> wrote:
> Andy,
>
> that's a good question. I have to admit that I thought about it and then
> saw that there is already an Authorizable for this scenario so I assumed
> that part was already taken care of. So whoever has the permission to view
> "access all policies" would also be able to use the API? Were you thinking
> of something different?
>
> Cheers,
> Lars
>
>
>
> On Fri, Nov 9, 2018 at 12:35 AM Andy LoPresto <al...@apache.org>
> wrote:
>
>> Lars,
>>
>> What access controls do you anticipate putting on this API endpoint and
>> what potential issues do you see? I could see this being abused if not
>> secured very carefully, and it doesn’t seem like a common use case
>> (notwithstanding your current requirement). Is this something that can be
>> done by using the NiFi CLI to iterate/recurse through the various PGs and
>> retrieve these policies?
>>
>> Andy LoPresto
>> alopresto@apache.org
>> alopresto.apache@gmail.com
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>
>> > On Nov 9, 2018, at 3:31 AM, Lars Francke <la...@gmail.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > I was tasked with writing a tool to generate a kind of "audit report".
>> For
>> > that I need to get all policies that people have across various systems.
>> > NiFi is one of them.
>> >
>> > I see that we have a REST API for Policies but that doesn't expose a
>> method
>> > to expose _all_ policies. I'd like to add a REST endpoint that allows
>> > retrieving all policies.
>> > Before I open a Jira I wanted to get feedback whether this addition
>> would
>> > be acceptable.
>> >
>> > Implementation notes
>> > This is how I see the current flow of requests from the
>> > AccessPolicyResource to the actual AccessPolicyProider:
>> >
>> > AccessPolicyResource -> NiFiServiceFacade (StandardNiFiServiceFacade) ->
>> > AccessPolicyDAO (StandardPolicyBasedAuthorizerDAO) ->
>> AccessPolicyProvider
>> >
>> > Fortunately the AccessPolicyProvider already has a method to retrieve
>> all
>> > policies. Should there be custom implementations by third-parties they
>> > already support the necessary methods and I believe the classes that
>> need
>> > to be changed are all NiFi internal:
>> >
>> > * AccessPolicyResource
>> > * NiFiServiceFacade
>> > * StandardNiFiServiceFacade
>> > * AccessPolicyDAO
>> > * StandardPolicyBasedAuthorizerDAO
>> > * And probably a bunch of others especially test classes
>> >
>> > If I don't hear any objections I will open a Jira issue and would try
>> and
>> > provide a patch.
>> >
>> > Cheers,
>> > Lars
>>
>>
Re: API to get all Policies
Posted by Lars Francke <la...@gmail.com>.
Andy,
that's a good question. I have to admit that I thought about it and then
saw that there is already an Authorizable for this scenario so I assumed
that part was already taken care of. So whoever has the permission to view
"access all policies" would also be able to use the API? Were you thinking
of something different?
Cheers,
Lars
On Fri, Nov 9, 2018 at 12:35 AM Andy LoPresto <al...@apache.org> wrote:
> Lars,
>
> What access controls do you anticipate putting on this API endpoint and
> what potential issues do you see? I could see this being abused if not
> secured very carefully, and it doesn’t seem like a common use case
> (notwithstanding your current requirement). Is this something that can be
> done by using the NiFi CLI to iterate/recurse through the various PGs and
> retrieve these policies?
>
> Andy LoPresto
> alopresto@apache.org
> alopresto.apache@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> > On Nov 9, 2018, at 3:31 AM, Lars Francke <la...@gmail.com> wrote:
> >
> > Hi,
> >
> > I was tasked with writing a tool to generate a kind of "audit report".
> For
> > that I need to get all policies that people have across various systems.
> > NiFi is one of them.
> >
> > I see that we have a REST API for Policies but that doesn't expose a
> method
> > to expose _all_ policies. I'd like to add a REST endpoint that allows
> > retrieving all policies.
> > Before I open a Jira I wanted to get feedback whether this addition would
> > be acceptable.
> >
> > Implementation notes
> > This is how I see the current flow of requests from the
> > AccessPolicyResource to the actual AccessPolicyProider:
> >
> > AccessPolicyResource -> NiFiServiceFacade (StandardNiFiServiceFacade) ->
> > AccessPolicyDAO (StandardPolicyBasedAuthorizerDAO) ->
> AccessPolicyProvider
> >
> > Fortunately the AccessPolicyProvider already has a method to retrieve all
> > policies. Should there be custom implementations by third-parties they
> > already support the necessary methods and I believe the classes that need
> > to be changed are all NiFi internal:
> >
> > * AccessPolicyResource
> > * NiFiServiceFacade
> > * StandardNiFiServiceFacade
> > * AccessPolicyDAO
> > * StandardPolicyBasedAuthorizerDAO
> > * And probably a bunch of others especially test classes
> >
> > If I don't hear any objections I will open a Jira issue and would try and
> > provide a patch.
> >
> > Cheers,
> > Lars
>
>
Re: API to get all Policies
Posted by Andy LoPresto <al...@apache.org>.
Lars,
What access controls do you anticipate putting on this API endpoint and what potential issues do you see? I could see this being abused if not secured very carefully, and it doesn’t seem like a common use case (notwithstanding your current requirement). Is this something that can be done by using the NiFi CLI to iterate/recurse through the various PGs and retrieve these policies?
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Nov 9, 2018, at 3:31 AM, Lars Francke <la...@gmail.com> wrote:
>
> Hi,
>
> I was tasked with writing a tool to generate a kind of "audit report". For
> that I need to get all policies that people have across various systems.
> NiFi is one of them.
>
> I see that we have a REST API for Policies but that doesn't expose a method
> to expose _all_ policies. I'd like to add a REST endpoint that allows
> retrieving all policies.
> Before I open a Jira I wanted to get feedback whether this addition would
> be acceptable.
>
> Implementation notes
> This is how I see the current flow of requests from the
> AccessPolicyResource to the actual AccessPolicyProider:
>
> AccessPolicyResource -> NiFiServiceFacade (StandardNiFiServiceFacade) ->
> AccessPolicyDAO (StandardPolicyBasedAuthorizerDAO) -> AccessPolicyProvider
>
> Fortunately the AccessPolicyProvider already has a method to retrieve all
> policies. Should there be custom implementations by third-parties they
> already support the necessary methods and I believe the classes that need
> to be changed are all NiFi internal:
>
> * AccessPolicyResource
> * NiFiServiceFacade
> * StandardNiFiServiceFacade
> * AccessPolicyDAO
> * StandardPolicyBasedAuthorizerDAO
> * And probably a bunch of others especially test classes
>
> If I don't hear any objections I will open a Jira issue and would try and
> provide a patch.
>
> Cheers,
> Lars