[
https://issues.apache.org/jira/browse/NIFI-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15415300#comment-15415300
]
Joe Skora commented on NIFI-2530:
---------------------------------
[~mcgilman], I agree with [~joewitt] regarding #2.
Policies at the template level and above make sense to me, but I have concerns
about policies within a template. Since polices tie to component instances
they will have to be abstracted for storage and instantiated when the template
is used, but if the instantiating flow is in a different security environment
the policies will still have to be dropped or translated somehow.
Tracking component policies within an instance would be useful, but that still
gets complex quickly. For example, if a user has access to the template and
flow but not to all components within the template, should they be allowed to
instantiate a template that they can't completely configure, etc?
> Template authorization - Fall back to Process Group
> ---------------------------------------------------
>
> Key: NIFI-2530
> URL: https://issues.apache.org/jira/browse/NIFI-2530
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Matt Gilman
> Assignee: Matt Gilman
> Priority: Blocker
> Fix For: 1.0.0
>
>
> Template authorization strategy in order:
> 1 - Explicit policy on template
> 2 - Authorize based on permissions of underlying components
> 3 - Authorize based on parent Process Group
> Currently, only 1 and 2 are checked. Need to fall back to parent Process
> Group.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
