[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-14 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512762#comment-16512762
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2703


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
> Fix For: 1.7.0
>
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-14 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512759#comment-16512759
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/2703
  
Thanks @markobean! This has been merged to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-14 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512570#comment-16512570
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/2703
  
Thanks for having a look. I'll include these when I merge in your changes.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-14 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512549#comment-16512549
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on the issue:

https://github.com/apache/nifi/pull/2703
  
I like the proposed changes. It makes the authorization process a bit 
cleaner. 
+1


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-13 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511307#comment-16511307
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/2703
  
Things are looking pretty good. I'd like to propose a few additional 
changes which I'm implemented here [1]. Please review them and let me know your 
thoughts. Thanks!

[1] 
https://github.com/mcgilman/nifi/commit/eed1be3dffcdd11d82746c1ba04bfd1ff68b5fc9


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509606#comment-16509606
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194730011
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1338,6 +1339,67 @@ private void authorizeReplay(final 
ProvenanceEventRecord event) {
 dataAuthorizable.authorize(authorizer, RequestAction.WRITE, user, 
eventAttributes);
 }
 
+private AuthorizationResult 
checkAuthorizationForData(ProvenanceEventRecord event) {
+final NiFiUser user = NiFiUserUtils.getNiFiUser();
+final Authorizable dataAuthorizable;
+if (event.isRemotePortType()) {
+dataAuthorizable = 
flowController.createRemoteDataAuthorizable(event.getComponentId());
+} else {
+dataAuthorizable = 
flowController.createLocalDataAuthorizable(event.getComponentId());
+}
+
+final Map eventAttributes = event.getAttributes();
+
+// ensure we can read the data
+return dataAuthorizable.checkAuthorization(authorizer, 
RequestAction.READ, user, eventAttributes);
+}
+
+private AuthorizationResult checkAuthorizationForProvenanceData(final 
ProvenanceEventRecord event) {
+final ProcessGroup rootGroup = 
flowController.getGroup(getRootGroupId());
+final NiFiUser user = NiFiUserUtils.getNiFiUser();
+final String componentId = event.getComponentId();
+Connectable connectable;
+String targetId = null;
+// check if the component is the rootGroup
+if (getRootGroupId().equals(componentId)) {
+targetId = componentId;
+}
+if (targetId == null) {
+// check if the component is a processor
+connectable = rootGroup.findProcessor(componentId);
+if (connectable == null) {
+// if the component id is not a processor then consider a 
connection
+connectable = 
rootGroup.findConnection(componentId).getSource();
+
+if (connectable == null) {
+throw new ResourceNotFoundException("The component 
that generated this event is no longer part of the data flow");
+}
+}
+targetId = connectable.getIdentifier();
+}
+final Authorizable provenanceDataAuthorizable = 
flowController.createProvenanceDataAuthorizable(targetId);
+
+return provenanceDataAuthorizable.checkAuthorization(authorizer, 
RequestAction.READ, user);
+}
+
+private AuthorizationResult checkConnectableAuthorization(final String 
componentId) {
+final ProcessGroup rootGroup = 
flowController.getGroup(getRootGroupId());
+final NiFiUser user = NiFiUserUtils.getNiFiUser();
+if (rootGroup.getIdentifier().equals(componentId)) {
+return rootGroup.checkAuthorization(authorizer, 
RequestAction.READ, user);
+}
+Connectable connectable = 
rootGroup.findLocalConnectable(componentId);
--- End diff --

Will findLocalConnectable() versus findProcessor() include connections as 
well? If so, then this should return to findProcessor() to account for 
connections and subsequently finding the connection's source component.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509585#comment-16509585
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on the issue:

https://github.com/apache/nifi/pull/2703
  
I believe the latest changes are demonstrating the intended functionality. 
Provenance events are only listed in the query results if the user has 'view 
provenance' on the corresponding component; flowfile content in the event 
details is only visible based on 'view the data' policy; component name and 
type is only visible based on 'view the component' policy (replaced with 
generic info such as UUID in place of name when policy is lacking.) I'll do 
some further testing today.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509577#comment-16509577
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194718895
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1489,6 +1492,12 @@ public int compare(AttributeDTO a1, AttributeDTO a2) 
{
 dto.setChildUuids(childUuids);
 }
 
+// lineage duration
+if (event.getLineageStartDate() > 0) {
--- End diff --

lineage duration was pulled out specifically because there was a case in 
which the duration was not properly populated. This was during early testing 
and may now be corrected by other changes. I will try to replicate.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509574#comment-16509574
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194718350
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1338,6 +1339,67 @@ private void authorizeReplay(final 
ProvenanceEventRecord event) {
 dataAuthorizable.authorize(authorizer, RequestAction.WRITE, user, 
eventAttributes);
 }
 
+private AuthorizationResult 
checkAuthorizationForData(ProvenanceEventRecord event) {
+final NiFiUser user = NiFiUserUtils.getNiFiUser();
+final Authorizable dataAuthorizable;
+if (event.isRemotePortType()) {
+dataAuthorizable = 
flowController.createRemoteDataAuthorizable(event.getComponentId());
+} else {
+dataAuthorizable = 
flowController.createLocalDataAuthorizable(event.getComponentId());
+}
+
+final Map eventAttributes = event.getAttributes();
+
+// ensure we can read the data
+return dataAuthorizable.checkAuthorization(authorizer, 
RequestAction.READ, user, eventAttributes);
+}
+
+private AuthorizationResult checkAuthorizationForProvenanceData(final 
ProvenanceEventRecord event) {
--- End diff --

I modified this method and checkConnectableAuthorization() to accomodate a 
Process Group being the event component. This is the case for DOWNLOAD 
provenance events.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508555#comment-16508555
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194513579
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/FlowController.java
 ---
@@ -4919,6 +4925,22 @@ private void updateRemoteProcessGroups() {
 return new 
ArrayList<>(provenanceRepository.getEvents(firstEventId, maxRecords));
 }
 
+public AuthorizationResult checkConnectableAuthorization(final String 
componentId) {
--- End diff --

Correct. This was moved to ControllerFacade.java. I will remove it from 
FlowController.java.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508548#comment-16508548
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194512038
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1389,104 +1420,119 @@ private ProvenanceEventDTO 
createProvenanceEventDto(final ProvenanceEventRecord
 // sets the component details if it can find the component still 
in the flow
 setComponentDetails(dto);
 
-// only include all details if not summarizing
-if (!summarize) {
-// convert the attributes
-final Comparator attributeComparator = new 
Comparator() {
-@Override
-public int compare(AttributeDTO a1, AttributeDTO a2) {
-return 
Collator.getInstance(Locale.US).compare(a1.getName(), a2.getName());
-}
-};
+//try {
+//AuthorizationResult result = 
flowController.checkConnectableAuthorization(event.getComponentId());
+AuthorizationResult result = 
checkConnectableAuthorization(event.getComponentId());
+if (Result.Denied.equals(result.getResult())) {
+dto.setComponentType("Processor"); // is this always a 
Processor?
+dto.setComponentName(dto.getComponentId());
+dto.setEventType("UNKNOWN");
--- End diff --

Yes, I agree. The event type should be controlled by the new provenance 
event policy. It is not controlled by the component policy that protects the 
component name and component type. 


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508544#comment-16508544
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194510876
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1389,104 +1420,119 @@ private ProvenanceEventDTO 
createProvenanceEventDto(final ProvenanceEventRecord
 // sets the component details if it can find the component still 
in the flow
 setComponentDetails(dto);
 
-// only include all details if not summarizing
-if (!summarize) {
-// convert the attributes
-final Comparator attributeComparator = new 
Comparator() {
-@Override
-public int compare(AttributeDTO a1, AttributeDTO a2) {
-return 
Collator.getInstance(Locale.US).compare(a1.getName(), a2.getName());
-}
-};
+//try {
+//AuthorizationResult result = 
flowController.checkConnectableAuthorization(event.getComponentId());
+AuthorizationResult result = 
checkConnectableAuthorization(event.getComponentId());
+if (Result.Denied.equals(result.getResult())) {
+dto.setComponentType("Processor"); // is this always a 
Processor?
+dto.setComponentName(dto.getComponentId());
+dto.setEventType("UNKNOWN");
--- End diff --

If we choose to _not_ redact event type, that makes life easier. Currently, 
it displays "UNKNOWN" in the table (when 'view provenance' is enabled and 'view 
the component' is not). But, the event type IS diplayed in the lineage graph. 
We need to get to consistency one way or the other on this. I'm leaning towards 
allowing the event type info to be visible since this is a characteristic of 
provenance (i.e. 'view provenance') and not a characteristic of 'view the 
component'.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508510#comment-16508510
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194499578
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1389,104 +1420,119 @@ private ProvenanceEventDTO 
createProvenanceEventDto(final ProvenanceEventRecord
 // sets the component details if it can find the component still 
in the flow
 setComponentDetails(dto);
 
-// only include all details if not summarizing
-if (!summarize) {
-// convert the attributes
-final Comparator attributeComparator = new 
Comparator() {
-@Override
-public int compare(AttributeDTO a1, AttributeDTO a2) {
-return 
Collator.getInstance(Locale.US).compare(a1.getName(), a2.getName());
-}
-};
+//try {
+//AuthorizationResult result = 
flowController.checkConnectableAuthorization(event.getComponentId());
+AuthorizationResult result = 
checkConnectableAuthorization(event.getComponentId());
+if (Result.Denied.equals(result.getResult())) {
+dto.setComponentType("Processor"); // is this always a 
Processor?
+dto.setComponentName(dto.getComponentId());
+dto.setEventType("UNKNOWN");
+}
 
-final SortedSet attributes = new 
TreeSet<>(attributeComparator);
+//authorizeData(event);
+final AuthorizationResult dataResult = 
checkAuthorizationForData(event); //(authorizer, RequestAction.READ, user, 
event.getAttributes());
 
-final Map updatedAttrs = 
event.getUpdatedAttributes();
-final Map previousAttrs = 
event.getPreviousAttributes();
+// only include all details if not summarizing and approved
+if (!summarize && 
Result.Approved.equals(dataResult.getResult())) {
--- End diff --

If the user is not authorized for the data of a component we should still 
be able to return a non-summary. In this case, we should just be leaving out 
any of the data fields in the ProvenanceEventDto. I would consider these fields 
data fields as they are associated with either attributes, content, or replay 
(all of which requires data policies to execute).

```
private Collection attributes;

private Boolean contentEqual;
private Boolean inputContentAvailable;
private String inputContentClaimSection;
private String inputContentClaimContainer;
private String inputContentClaimIdentifier;
private Long inputContentClaimOffset;
private String inputContentClaimFileSize;
private Long inputContentClaimFileSizeBytes;
private Boolean outputContentAvailable;
private String outputContentClaimSection;
private String outputContentClaimContainer;
private String outputContentClaimIdentifier;
private Long outputContentClaimOffset;
private String outputContentClaimFileSize;
private Long outputContentClaimFileSizeBytes;

private Boolean replayAvailable;
private String replayExplanation;
private String sourceConnectionIdentifier;
```


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508505#comment-16508505
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194495379
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/FlowController.java
 ---
@@ -4919,6 +4925,22 @@ private void updateRemoteProcessGroups() {
 return new 
ArrayList<>(provenanceRepository.getEvents(firstEventId, maxRecords));
 }
 
+public AuthorizationResult checkConnectableAuthorization(final String 
componentId) {
--- End diff --

I don't believe this is called.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508507#comment-16508507
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194498155
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1389,104 +1420,119 @@ private ProvenanceEventDTO 
createProvenanceEventDto(final ProvenanceEventRecord
 // sets the component details if it can find the component still 
in the flow
 setComponentDetails(dto);
 
-// only include all details if not summarizing
-if (!summarize) {
-// convert the attributes
-final Comparator attributeComparator = new 
Comparator() {
-@Override
-public int compare(AttributeDTO a1, AttributeDTO a2) {
-return 
Collator.getInstance(Locale.US).compare(a1.getName(), a2.getName());
-}
-};
+//try {
+//AuthorizationResult result = 
flowController.checkConnectableAuthorization(event.getComponentId());
+AuthorizationResult result = 
checkConnectableAuthorization(event.getComponentId());
+if (Result.Denied.equals(result.getResult())) {
+dto.setComponentType("Processor"); // is this always a 
Processor?
+dto.setComponentName(dto.getComponentId());
+dto.setEventType("UNKNOWN");
+}
 
-final SortedSet attributes = new 
TreeSet<>(attributeComparator);
+//authorizeData(event);
+final AuthorizationResult dataResult = 
checkAuthorizationForData(event); //(authorizer, RequestAction.READ, user, 
event.getAttributes());
--- End diff --

We only need to authorize for the data if the event is a non-summary. For 
instance, when we're pulling back 1000 summaries to load the provenance table 
we don't need to check any data policies.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508508#comment-16508508
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194496260
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1389,104 +1420,119 @@ private ProvenanceEventDTO 
createProvenanceEventDto(final ProvenanceEventRecord
 // sets the component details if it can find the component still 
in the flow
 setComponentDetails(dto);
 
-// only include all details if not summarizing
-if (!summarize) {
-// convert the attributes
-final Comparator attributeComparator = new 
Comparator() {
-@Override
-public int compare(AttributeDTO a1, AttributeDTO a2) {
-return 
Collator.getInstance(Locale.US).compare(a1.getName(), a2.getName());
-}
-};
+//try {
+//AuthorizationResult result = 
flowController.checkConnectableAuthorization(event.getComponentId());
+AuthorizationResult result = 
checkConnectableAuthorization(event.getComponentId());
+if (Result.Denied.equals(result.getResult())) {
+dto.setComponentType("Processor"); // is this always a 
Processor?
+dto.setComponentName(dto.getComponentId());
+dto.setEventType("UNKNOWN");
--- End diff --

Do you think that we need to redact the event type when the user does not 
have permissions to the component policy? I would have considered this field 
under the new provenance event policy.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508506#comment-16508506
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194495873
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1389,104 +1420,119 @@ private ProvenanceEventDTO 
createProvenanceEventDto(final ProvenanceEventRecord
 // sets the component details if it can find the component still 
in the flow
 setComponentDetails(dto);
 
-// only include all details if not summarizing
-if (!summarize) {
-// convert the attributes
-final Comparator attributeComparator = new 
Comparator() {
-@Override
-public int compare(AttributeDTO a1, AttributeDTO a2) {
-return 
Collator.getInstance(Locale.US).compare(a1.getName(), a2.getName());
-}
-};
+//try {
+//AuthorizationResult result = 
flowController.checkConnectableAuthorization(event.getComponentId());
+AuthorizationResult result = 
checkConnectableAuthorization(event.getComponentId());
--- End diff --

Why not check the authorization within `setComponentDetails`? In there you 
already have the components to authorize and you'll know the corresponding type.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-11 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508509#comment-16508509
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r194503331
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1389,104 +1420,119 @@ private ProvenanceEventDTO 
createProvenanceEventDto(final ProvenanceEventRecord
 // sets the component details if it can find the component still 
in the flow
 setComponentDetails(dto);
 
-// only include all details if not summarizing
-if (!summarize) {
-// convert the attributes
-final Comparator attributeComparator = new 
Comparator() {
-@Override
-public int compare(AttributeDTO a1, AttributeDTO a2) {
-return 
Collator.getInstance(Locale.US).compare(a1.getName(), a2.getName());
-}
-};
+//try {
+//AuthorizationResult result = 
flowController.checkConnectableAuthorization(event.getComponentId());
+AuthorizationResult result = 
checkConnectableAuthorization(event.getComponentId());
+if (Result.Denied.equals(result.getResult())) {
+dto.setComponentType("Processor"); // is this always a 
Processor?
+dto.setComponentName(dto.getComponentId());
+dto.setEventType("UNKNOWN");
+}
 
-final SortedSet attributes = new 
TreeSet<>(attributeComparator);
+//authorizeData(event);
+final AuthorizationResult dataResult = 
checkAuthorizationForData(event); //(authorizer, RequestAction.READ, user, 
event.getAttributes());
--- End diff --

Also, it appears that we're checking the checkAuthorizationForData is 
verifying READ to the data of the corresponding component. This check is 
already done as part of the checkAuthorizationForReplay method. It appears that 
is the only place the replay authorization check is performed. It likely makes 
sense to refactor some of this so that we're only checking permissions for READ 
to the data of the corresponding component once. The remainder of the replay 
authorization check only needs to be performed when we're populating the data 
fields (READ to the data of the corresponding component is approved). See below.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-07 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504908#comment-16504908
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/2703
  
@markobean I just ran your PR and I'm not seeing the same behavior you are 
describing. Even without the component policy, I'm able to view the provenance 
event. This is the behavior I was expecting to see following the discussion on 
the JIRA. It's possible that we're using the same language to refer to 
different things. Let me try to elaborate/clarify a bit here.

/processors/1234 - component policy (controls access to a component and its 
config)
/provenance-data/processors/1234 - comopnent provenance event policy 
(controls access to the provenance events from a component)
/data/processors/1234 - component data policy (controls access to the data 
from a component including flowfile attributes)

The line you referenced should only verify access to the component 
provenance event (and it appears that's how it's working). It should not be 
checking the component policy. My suggestion was to additionally check the 
component policy prior to populating the component details 
(`setComponentDetails`). This would be in line with your initial comment on 
this JIRA.

With your most recent changes, I'm not sure its functionality is different 
than before. It seems that it would be impossible to get a non-summarized event 
without permissions to the data of the component. I think we only need to 
verify permissions to data of a component for the attributes and the content 
specific fields. Other fields should be ok, allowing for a non-summarized event 
for folks without access to a component's data.

It appears that `checkAuthorizationForReplay` was also verifying that the 
connection that would be replayed into still exists. This would affect the 
availability of the replay action. Also, while a little nit-picky, I would also 
suggest using the `checkAuthorization...` methods which return an 
`AuthorizationResult` instead of relying on an `Exception` during a 
non-exceptional case. The generation of the stack trace is an expensive 
operation.

Also, it does not seem like you updated or replied to my comment regarding 
the need to include the flowfile attributes when authorizing access to 
component's provenance events. I think these are only necessary when 
authorizing access to a component's data.

Please do not squash additional commits. It makes it difficult to review 
when I cannot easily see the incremental changes. 

Thanks!


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-06 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504138#comment-16504138
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on the issue:

https://github.com/apache/nifi/pull/2703
  
When calling getEvent() from the provenance repository, the user is 
authorized for the event (including component level authorization). See 
ControllerFacade.java:1353. This getEvent() method call is prior to 
createProvenanceEventDto(). So, it would be redundant to authorize the user for 
the event inside createProvenanceEventDto() as any unauthorized events will 
have already been filtered out. The original approach was to exclude all events 
from a provenance query result for which the user is not authorized (e.g. the 
user is not in the 'view provenance' component level policy). Therefore, it 
should not be necessary to perform your point #2 above.

For point #3 and a slight refactor of authorizeReplay(), I've renamed it to 
authorizeData(). And, removed the duplicate authorization block from 
getProvenanceEvent(). Instead, the createProvenanceEventDto() will perform the 
data authorization prior to the if !summarize block. In this way, the event 
will need to be authorized for data access as well as not summarized in order 
for the dto to populate the attributes and content.

I also updated some authorization unit tests with more detailed expected 
results. And, rebased to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-01 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498439#comment-16498439
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r192493550
  
--- Diff: 
nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/WriteAheadProvenanceRepository.java
 ---
@@ -226,12 +226,7 @@ private void authorize(final ProvenanceEventRecord 
event, final NiFiUser user) {
 return;
 }
 
-final Authorizable eventAuthorizable;
-if (event.isRemotePortType()) {
-eventAuthorizable = 
resourceFactory.createRemoteDataAuthorizable(event.getComponentId());
-} else {
-eventAuthorizable = 
resourceFactory.createLocalDataAuthorizable(event.getComponentId());
-}
+final Authorizable eventAuthorizable = 
resourceFactory.createProvenanceDataAuthorizable(event.getComponentId());
 eventAuthorizable.authorize(authorizer, RequestAction.READ, user, 
event.getAttributes());
--- End diff --

I don't think the attributes are necessary here. I'm pretty sure the event 
attributes would be necessary for authorizing access to attributes/content.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-01 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498438#comment-16498438
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r192493635
  
--- Diff: 
nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-volatile-provenance-repository/src/main/java/org/apache/nifi/provenance/VolatileProvenanceRepository.java
 ---
@@ -280,12 +276,7 @@ protected void authorize(final ProvenanceEventRecord 
event, final NiFiUser user)
 return;
 }
 
-final Authorizable eventAuthorizable;
-if (event.isRemotePortType()) {
-eventAuthorizable = 
resourceFactory.createRemoteDataAuthorizable(event.getComponentId());
-} else {
-eventAuthorizable = 
resourceFactory.createLocalDataAuthorizable(event.getComponentId());
-}
+final Authorizable eventAuthorizable = 
resourceFactory.createProvenanceDataAuthorizable(event.getComponentId());
 eventAuthorizable.authorize(authorizer, RequestAction.READ, user, 
event.getAttributes());
--- End diff --

I don't think the attributes are necessary here. I'm pretty sure the event 
attributes would be necessary for authorizing access to attributes/content.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-01 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498436#comment-16498436
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r192493531
  
--- Diff: 
nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java
 ---
@@ -403,12 +399,7 @@ public void authorize(final ProvenanceEventRecord 
event, final NiFiUser user) {
 return;
 }
 
-final Authorizable eventAuthorizable;
-if (event.isRemotePortType()) {
-eventAuthorizable = 
resourceFactory.createRemoteDataAuthorizable(event.getComponentId());
-} else {
-eventAuthorizable = 
resourceFactory.createLocalDataAuthorizable(event.getComponentId());
-}
+final Authorizable eventAuthorizable = 
resourceFactory.createProvenanceDataAuthorizable(event.getComponentId());
 eventAuthorizable.authorize(authorizer, RequestAction.READ, user, 
event.getAttributes());
--- End diff --

I don't think the attributes are necessary here. I'm pretty sure the event 
attributes would be necessary for authorizing access to attributes/content.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-01 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498437#comment-16498437
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r192493603
  
--- Diff: 
nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/authorization/UserEventAuthorizer.java
 ---
@@ -65,12 +61,7 @@ public void authorize(final ProvenanceEventRecord event) 
{
 return;
 }
 
-final Authorizable eventAuthorizable;
-if (event.isRemotePortType()) {
-eventAuthorizable = 
resourceFactory.createRemoteDataAuthorizable(event.getComponentId());
-} else {
-eventAuthorizable = 
resourceFactory.createLocalDataAuthorizable(event.getComponentId());
-}
+final Authorizable eventAuthorizable = 
resourceFactory.createProvenanceDataAuthorizable(event.getComponentId());
 eventAuthorizable.authorize(authorizer, RequestAction.READ, user, 
event.getAttributes());
--- End diff --

I don't think the attributes are necessary here. I'm pretty sure the event 
attributes would be necessary for authorizing access to attributes/content.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-01 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498430#comment-16498430
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r192492247
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1359,7 +1363,12 @@ public ProvenanceEventDTO getProvenanceEvent(final 
Long eventId) {
 } else {
 dataAuthorizable = 
flowController.createLocalDataAuthorizable(event.getComponentId());
 }
-dataAuthorizable.authorize(authorizer, RequestAction.READ, 
NiFiUserUtils.getNiFiUser(), attributes);
+// If not authorized for 'view the data', create only 
summarized provenance event
--- End diff --

The original JIRA called to make this more granular because using the data 
policies was too blunt. In the PR as-is, for each event it appears that we 
authorize the event and then authorize the data policies twice. We are 
authorizing the data policy to determine if we should summarize and then again 
to determine if replay is authorized. The replay portion is not changed/new in 
this PR but is an area for improvement we could make now.

Since we're taking this more granular approach I agree with your originally 
filed JIRA to add the additional component based check. This shouldn't 
introduce too much additional cost. The component checks do not consider flow 
file attributes and the results should be easily cached. 

Another improvement that I didn't call out specifically above, is that we 
really only need to check the data policies if we are not summarizing. Whether 
the user is approved for data of a component would only be relevant if we were 
returning the fully populated event.

In order to return the summary, we only need to check the policies for the 
event and the component. Like the component policies, I don't _think_ the flow 
file attributes would need to be considered for the event policies. I believe 
the attributes would only need to be considered for the data policies where we 
are actually returning the attributes and content. This should help with some 
of the performance concerns regarding frequent authorization.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-06-01 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498059#comment-16498059
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r192413226
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1359,7 +1363,12 @@ public ProvenanceEventDTO getProvenanceEvent(final 
Long eventId) {
 } else {
 dataAuthorizable = 
flowController.createLocalDataAuthorizable(event.getComponentId());
 }
-dataAuthorizable.authorize(authorizer, RequestAction.READ, 
NiFiUserUtils.getNiFiUser(), attributes);
+// If not authorized for 'view the data', create only 
summarized provenance event
--- End diff --

My only concern with the approach you outlined is the additional 
authorizations calls to determine "if the user is allowed". What you suggest 
requires up to 2 additional authorizations per provenance event. Already on 
busy systems, we have observed authorizing the user to each provenance event as 
a limiting factor (it can result in provenance becoming unusable).  
Having said that, unless you think of another approach which would require 
fewer authorizations calls, I'll proceed as you recommend. I suspect there may 
be a future JIRA ticket to address the provenance query/authorization impact 
anyhow; if so, this can be addressed at that time. We won't know for sure if 
this is a problem until we get the current fix into an appropriately loaded 
test environment.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-29 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493573#comment-16493573
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191444067
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1359,7 +1363,12 @@ public ProvenanceEventDTO getProvenanceEvent(final 
Long eventId) {
 } else {
 dataAuthorizable = 
flowController.createLocalDataAuthorizable(event.getComponentId());
 }
-dataAuthorizable.authorize(authorizer, RequestAction.READ, 
NiFiUserUtils.getNiFiUser(), attributes);
+// If not authorized for 'view the data', create only 
summarized provenance event
--- End diff --

@markobean The summary concept was introduced for performance reasons [1]. 
The summary represents the details required to render a row in the table. Some 
events can contain a lot of details (many children/parents UUIDs, flowfile 
attributes, etc) which was causing the table to load extremely slowly. The 
fully populated event (not summary) is returned once a dialog is opened and 
those details can be rendered.

My suggestion would be to not modify the summary concept. Returning more 
details in the summary for users with access to the event but not the data will 
begin to regress NIFI-1135. Artificially withholding event fields they should 
have access to also doesn't seem right.

Since we're moving to this super granular approach, I would recommend the 
following. 

1) `createProvenanceEventDto(...)` is only invoked once we know the user 
has permissions to the event.
2) Within `createProvenanceEventDto(...)` I would check if the user is 
allowed to access that component to populate the component details. If the user 
does not have access, I would use the ID in place of the name and 'Processor' 
in place of the fully qualified class name (for Processors).
3) Within `createProvenanceEventDto(...)` I would check if the user is 
allowed to access the component's data to populate the attributes and content 
details. If the user does not have access, I would leave those fields unset.

This should retain the summary concept while introducing the granular 
approach we're looking for. Thoughts?

[1] https://issues.apache.org/jira/browse/NIFI-1135


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491729#comment-16491729
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191053294
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1359,7 +1363,12 @@ public ProvenanceEventDTO getProvenanceEvent(final 
Long eventId) {
 } else {
 dataAuthorizable = 
flowController.createLocalDataAuthorizable(event.getComponentId());
 }
-dataAuthorizable.authorize(authorizer, RequestAction.READ, 
NiFiUserUtils.getNiFiUser(), attributes);
+// If not authorized for 'view the data', create only 
summarized provenance event
--- End diff --

The summarized event does seem to exclude other details that do not fall 
under 'view the data' (i.e. attributes and content.) For example, event 
duration and parent/child UUIDs. It seems either more event details besides 
lineageStartDate need to be moved out of the "if (!summarized)" block, or... 
what else would you suggest? A new method to generate the ProvenanceEventDTO 
which explicitly excludes all attributes and content?


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491715#comment-16491715
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191052573
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
 
 
 The last segment of each property is an identifier used to associate the 
pattern with the replacement value.  When a user makes a request to NiFi, their 
identity is checked to see if it matches each of those patterns in 
lexicographical order.  For the first one that matches, the replacement 
specified in the `nifi.security.identity.mapping.value.` property is used. 
So a login with `CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, 
C=US` matches the DN mapping pattern above and the DN mapping value `$1@$2` is 
applied.  The user is normalized to `localhost@Apache NiFi`.
 
-In addition to mapping a transform may be applied. The supported versions 
are NONE (no transform applied), LOWER (identity lowercased), and UPPER 
(identity uppercased). If not specified, the default value is NONE.
--- End diff --

Somehow, there was a bad rebase to master which removed some recently 
modified lines. Re-rebased to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491718#comment-16491718
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191052587
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/RoleAccessPolicy.java
 ---
@@ -63,7 +63,7 @@ public String getAction() {
 final Set provenancePolicies = new HashSet<>();
 provenancePolicies.add(new 
RoleAccessPolicy(ResourceType.Provenance.getValue(), READ_ACTION));
 if (rootGroupId != null) {
-provenancePolicies.add(new 
RoleAccessPolicy(ResourceType.Data.getValue() + 
ResourceType.ProcessGroup.getValue() + "/" + rootGroupId, READ_ACTION));
+provenancePolicies.add(new 
RoleAccessPolicy(ResourceType.ProvenanceData.getValue() + 
ResourceType.ProcessGroup.getValue() + "/" + rootGroupId, READ_ACTION));
--- End diff --

Agree. Added Data back in.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491716#comment-16491716
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191052575
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
 
 
 The last segment of each property is an identifier used to associate the 
pattern with the replacement value.  When a user makes a request to NiFi, their 
identity is checked to see if it matches each of those patterns in 
lexicographical order.  For the first one that matches, the replacement 
specified in the `nifi.security.identity.mapping.value.` property is used. 
So a login with `CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, 
C=US` matches the DN mapping pattern above and the DN mapping value `$1@$2` is 
applied.  The user is normalized to `localhost@Apache NiFi`.
 
-In addition to mapping a transform may be applied. The supported versions 
are NONE (no transform applied), LOWER (identity lowercased), and UPPER 
(identity uppercased). If not specified, the default value is NONE.
--- End diff --

Somehow, there was a bad rebase to master which removed some recently 
modified lines. Re-rebased to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491714#comment-16491714
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191052568
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
--- End diff --

Somehow, there was a bad rebase to master which removed some recently 
modified lines. Re-rebased to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491711#comment-16491711
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191052561
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
--- End diff --

Somehow, there was a bad rebase to master which removed some recently 
modified lines. Re-rebased to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491713#comment-16491713
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191052566
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
--- End diff --

Somehow, there was a bad rebase to master which removed some recently 
modified lines. Re-rebased to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491712#comment-16491712
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r191052564
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
--- End diff --

Somehow, there was a bad rebase to master which removed some recently 
modified lines. Re-rebased to master.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490927#comment-16490927
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190909574
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
--- End diff --

Did you intend to remove this?


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490935#comment-16490935
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190938627
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1359,7 +1363,12 @@ public ProvenanceEventDTO getProvenanceEvent(final 
Long eventId) {
 } else {
 dataAuthorizable = 
flowController.createLocalDataAuthorizable(event.getComponentId());
 }
-dataAuthorizable.authorize(authorizer, RequestAction.READ, 
NiFiUserUtils.getNiFiUser(), attributes);
+// If not authorized for 'view the data', create only 
summarized provenance event
--- End diff --

I believe the event summaries are what's necessary to populate the table. 
However, even if the user does not have 'view the data' they can still open the 
event dialog. Shouldn't we be returning more than a summary? The event should 
include everything but the attributes and content fields. Piggybacking on the 
summarization concept could inadvertently change this if we ever change what 
comprises a summary (if we change the table for instance).


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490925#comment-16490925
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190909631
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
 
 
 The last segment of each property is an identifier used to associate the 
pattern with the replacement value.  When a user makes a request to NiFi, their 
identity is checked to see if it matches each of those patterns in 
lexicographical order.  For the first one that matches, the replacement 
specified in the `nifi.security.identity.mapping.value.` property is used. 
So a login with `CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, 
C=US` matches the DN mapping pattern above and the DN mapping value `$1@$2` is 
applied.  The user is normalized to `localhost@Apache NiFi`.
 
-In addition to mapping a transform may be applied. The supported versions 
are NONE (no transform applied), LOWER (identity lowercased), and UPPER 
(identity uppercased). If not specified, the default value is NONE.
--- End diff --

Did you intend to remove this?


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490934#comment-16490934
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190921858
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/FlowController.java
 ---
@@ -3464,10 +3462,6 @@ public ReportingTaskNode createReportingTask(final 
String type, final String id,
 
 LoggableComponent task = null;
 boolean creationSuccessful = true;
-
-// make sure the first reference to LogRepository happens outside 
of a NarCloseable so that we use the framework's ClassLoader
-final LogRepository logRepository = 
LogRepositoryFactory.getRepository(id);
--- End diff --

I don't think we can move this line. This needs to happen outside of the 
NarCloseable. Please refer to JIRA it was added for additional information. 
https://issues.apache.org/jira/browse/NIFI-5136


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490932#comment-16490932
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190919397
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
 
 
 The last segment of each property is an identifier used to associate the 
pattern with the replacement value.  When a user makes a request to NiFi, their 
identity is checked to see if it matches each of those patterns in 
lexicographical order.  For the first one that matches, the replacement 
specified in the `nifi.security.identity.mapping.value.` property is used. 
So a login with `CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, 
C=US` matches the DN mapping pattern above and the DN mapping value `$1@$2` is 
applied.  The user is normalized to `localhost@Apache NiFi`.
 
-In addition to mapping a transform may be applied. The supported versions 
are NONE (no transform applied), LOWER (identity lowercased), and UPPER 
(identity uppercased). If not specified, the default value is NONE.
--- End diff --

Did you intend to remove this?


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490931#comment-16490931
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190939869
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
 ---
@@ -1489,6 +1492,12 @@ public int compare(AttributeDTO a1, AttributeDTO a2) 
{
 dto.setChildUuids(childUuids);
 }
 
+// lineage duration
+if (event.getLineageStartDate() > 0) {
--- End diff --

If we don't piggyback off of summarization, I believe this can be moved 
back.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490929#comment-16490929
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190919423
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
--- End diff --

Did you intend to remove this?


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490926#comment-16490926
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190909604
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
--- End diff --

Did you intend to remove this?


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490928#comment-16490928
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190919318
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/RoleAccessPolicy.java
 ---
@@ -63,7 +63,7 @@ public String getAction() {
 final Set provenancePolicies = new HashSet<>();
 provenancePolicies.add(new 
RoleAccessPolicy(ResourceType.Provenance.getValue(), READ_ACTION));
 if (rootGroupId != null) {
-provenancePolicies.add(new 
RoleAccessPolicy(ResourceType.Data.getValue() + 
ResourceType.ProcessGroup.getValue() + "/" + rootGroupId, READ_ACTION));
+provenancePolicies.add(new 
RoleAccessPolicy(ResourceType.ProvenanceData.getValue() + 
ResourceType.ProcessGroup.getValue() + "/" + rootGroupId, READ_ACTION));
--- End diff --

In order to be consistent with our 0.x concept of provenance access, this 
should include both ProvenanceData and Data.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490930#comment-16490930
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190921803
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/FlowController.java
 ---
@@ -1152,10 +1153,6 @@ public ProcessorNode createProcessor(final String 
type, String id, final BundleC
 
 boolean creationSuccessful;
 LoggableComponent processor;
-
-// make sure the first reference to LogRepository happens outside 
of a NarCloseable so that we use the framework's ClassLoader
-final LogRepository logRepository = 
LogRepositoryFactory.getRepository(id);
--- End diff --

I don't think we can move this line. This needs to happen outside of the 
NarCloseable. Please refer to JIRA it was added for additional information. 
https://issues.apache.org/jira/browse/NIFI-5136


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490933#comment-16490933
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190921900
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/FlowController.java
 ---
@@ -3669,12 +3664,10 @@ public FlowRegistryClient getFlowRegistryClient() {
 
 @Override
 public ControllerServiceNode createControllerService(final String 
type, final String id, final BundleCoordinate bundleCoordinate, final Set 
additionalUrls, final boolean firstTimeAdded) {
-// make sure the first reference to LogRepository happens outside 
of a NarCloseable so that we use the framework's ClassLoader
-final LogRepository logRepository = 
LogRepositoryFactory.getRepository(id);
--- End diff --

I don't think we can move this line. This needs to happen outside of the 
NarCloseable. Please refer to JIRA it was added for additional information. 
https://issues.apache.org/jira/browse/NIFI-5136


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-25 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490936#comment-16490936
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2703#discussion_r190919443
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3424,27 +3429,13 @@ The following examples demonstrate normalizing DNs 
from certificates and princip
 
 nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), 
L=(.*?), ST=(.*?), C=(.*?)$
 nifi.security.identity.mapping.value.dn=$1@$2
-nifi.security.identity.mapping.transform.dn=NONE
 nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
 nifi.security.identity.mapping.value.kerb=$1@$2
-nifi.security.identity.mapping.transform.kerb=NONE
--- End diff --

Did you intend to remove this?


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-23 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487599#comment-16487599
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/2703
  
Will review...


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-18 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481244#comment-16481244
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

Github user markobean commented on the issue:

https://github.com/apache/nifi/pull/2703
  
Fixed conflicts with master.
Added NIFI-5207 since it is from the same policy refactor and required 
minimal code change.


> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-14 Thread Mark Bean (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475118#comment-16475118
 ] 

Mark Bean commented on NIFI-4907:
-

In addition to basic unit testing, performed the following integration testing 
steps:

 

Remove ‘query provenance’ Global Policy; remove ‘view provenance’ Component 
Policy

Cannot query provenance; Global menu item grayed out; component menu item not 
displayed

Add ‘view provenance’ Component Policy at root Process Group. Still Global menu 
item grayed out; component menu item not displayed

Remove ‘view provenance’ Component Policy at root Process Group.

 

Create ‘query provenance’ Global Policy; add user

Global ‘Data Provenance’ runs query, but does not display any results

Component ‘View data provenance’ runs query, but does not display any results

 

Create ‘view provenance’ Component Policy at root Process Group; add user

Global ‘Data Provenance’ runs query, and displays all event results; Lineage 
graph displays all provenance events. Additional details are not available from 
the query results list nor lineage graph.

 

Create ‘view the data’ Component Policy at root Process Group; add user.

Global ‘Data Provenance’ runs query, and displays all event results; Lineage 
graph displays all provenance events. Additional details are available from the 
query results list and lineage graph.

 

Override ‘view provenance’ Component Policy for one component (e.g. 
GenerateFlowFile). 

Global ‘Data Provenance’ runs query, and displays all event results except 
CREATE event associated with Component whose policy was overridden. Lineage 
graph displays all provenance events with “CREATE” event being replaced by 
“UNKNOWN”. Attempting to double-click on the “UNKNOWN” event results in 
“Insufficient Permissions: Unable to view the provenance data for Processor 
with ID \{UUID}. Contact the system administrator.” Other lineage events allow 
access to additional details when double-clicked.

Component ‘View data provenance’ runs query, but does not display any results

 

Repeat with consistent results for Persistent, Volatile and Write-Ahead 
Provenance repository types

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-14 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475117#comment-16475117
 ] 

ASF GitHub Bot commented on NIFI-4907:
--

GitHub user markobean opened a pull request:

https://github.com/apache/nifi/pull/2703

NIFI-4907: add 'view provenance' component policy

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markobean/nifi NIFI-4907

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2703.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2703


commit eed76e9aa2891eeccb7ef4bb4a5890a178aa7a8f
Author: Mark Bean 
Date:   2018-05-12T20:32:29Z

NIFI-4907: add 'view provenance' component policy




> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. 

[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-14 Thread Matt Gilman (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474537#comment-16474537
 ] 

Matt Gilman commented on NIFI-4907:
---

An endpoint could be categorized as data plane (downloading or manipulating 
attributes/content, etc) or control plane (configuring a component, etc - 
basically anything not data plane). For data plane endpoints, NiFi requires the 
entire chain to be authorized. This allows the authorizer to verify that an end 
user can have the data and that any proxy in the chain is also authorized to 
have the data (since the data is ultimately routing through those servers). In 
a NiFi cluster, any node can act as the Cluster Coorindator which replicates 
(routes) the requests to any/all nodes.

The existing 'view the data' policies would be considered data plane. I do not 
believe that the provenance event details would be considered data and would 
only require the end user has the necessary permission.

The authorization in this case would be:

1) Ensure the user is allowed to 'query provenance'

For each event

2) Ensure the user is allowed to 'view provenance' for the component

For each authorized event

3) Include component name/type if the user is allowed to 'view component'

4) Include attributes and content details if the user is allowed to 'view the 
data' for the component

Step (1) should already be in place. As part of this PR, you should be 
adding/updating (2), (3), and (4). In order to do (2), you'll need to add 
support for viewing/configuring the 'view provenance' policy for each 
component. Hope this helps.

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-13 Thread Mark Bean (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473570#comment-16473570
 ] 

Mark Bean commented on NIFI-4907:
-

WIP code is at: https://github.com/markobean/nifi/tree/NIFI-4907

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-05-13 Thread Mark Bean (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473565#comment-16473565
 ] 

Mark Bean commented on NIFI-4907:
-

I'm returning to NIFI-4907. It's been on the back burner for a while, and I'm 
ready to get it wrapped up now. I ran into an issue though. I based the new 
'view provenance' Component Policy on the 'view the data' policy. However, the 
authorization chain is not implemented (correctly). And, I'm wondering if it 
needs to be implemented at all.
 
In general, I'm not entirely clear on the authorization chain. By usage, I know 
'view the data' requires both the user and the cluster nodes (if clustered) in 
the policy. I believe this is part of the authorization chain. Can you explain 
why this is necessary? Secondly, would this be required for the 'view 
provenance' Component Policy as well?
 
I have not tested my code in a cluster environment, but it is working just fine 
in a single instance. It's the ProvenanceDataAuthorizableTest unit tests 
(replicated in large part from DataAuthorizableTest class) that are failing. 
And, I suspect if I put this in a cluster environment, it may not behave as 
needed - if authorization chaining is required.

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-02-27 Thread Matt Gilman (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379192#comment-16379192
 ] 

Matt Gilman commented on NIFI-4907:
---

Following an offline discussion with [~markbean], I have a better understanding 
of the issue at hand. Using the 'view the data' policies to enforce permissions 
on flowfile attributes, flowfile content, and provenance events is too blunt. 
To address this concern and maintain a good multi-tenant user experience a 
component-based 'view provenance' permission should be introduced. 

This new policy would allow for the retrieval of provenance events for that 
component. Whether the attributes and content are available as part of that 
event should be driven by the 'view the data' policies for that component. This 
would allow for users to be able to access the provenance event, but not be 
exposed to the sensitive flowfile attributes and contents if desired (by adding 
the user to 'view provenance' but not 'view the data').

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-02-27 Thread Matt Gilman (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378820#comment-16378820
 ] 

Matt Gilman commented on NIFI-4907:
---

[~markbean]

I think there may still be a slight misunderstanding. I was suggesting in the 
last paragraph of my response that the provenance event model contains some 
details about the source component (type, processor name, port name, connection 
name) relevant for understanding/consuming the event. These are available to 
users that have 'view the data' permissions for that component. They are not 
available for anyone with 'query provenance'. The 'query provenance' policy 
simply dictates whether a particular user is allowed to make a provenance query 
which itself can be resource intensive.

The current documentation is admittedly vague as it indicates that the 'view 
the data' policy controls content and metadata for provenance events and queued 
flowfiles. I'd be happy to update this to call out that the provenance event 
details include may include component name and type.

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-02-27 Thread Mark Bean (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378613#comment-16378613
 ] 

Mark Bean commented on NIFI-4907:
-

Matt,

I understand the argument for provenance being event centric which by its 
nature is [meta]data centric. However, that still leaves the conflict of 
providing component level information in a provenance event to which the user 
may not have sufficient access. By this logic, the graph should display the 
processor name/type if a user is in the 'view the data' policy which I think we 
can agree is not correct.


Fundamentally, this seems to still an issue. Unless, it is understood (and 
clearly documented) that 'query provenance' policy indirectly includes the 
permission to view the component name and type of any component which generates 
provenance events.

-Mark

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the 
> corresponding component policy 'view the data'. Inability to display event 
> details should provide feedback to the user indicating the reason.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4907) Provenance authorization refactoring

2018-02-26 Thread Matt Gilman (JIRA)

[ 
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16377329#comment-16377329
 ] 

Matt Gilman commented on NIFI-4907:
---

[~markbean] 

Thanks for taking the time for writing up such a detailed synopsis. These 
provenance query capabilities were designed in support of multi-tenant flow 
management. In these multi-tenant environments, users only have access to a 
small subset of the components in NiFi flow.

Returning placeholder events for unauthorized components was certainly 
considered for query results. However, considering these multi-tenant 
scenarios, returning placeholder events would make more work for the user to 
filter through these or perform more complex searches. Since the results are 
event centric, automatically filtering these out was the better approach. While 
inconsistent with provenance queries, returning placeholder events did make 
sense for lineage requests since those are lineage centric. The lineage is a 
sequence of events that only makes sense as a whole.

'View the data' policies are used to enforce access to content and metadata. 
This includes the actual data of the flowfile (content), the attributes of the 
flowfile and details of the event (metadata). The details of the event include 
bits about the event and the component that generated it including the 
component name (processor, port, or connection) and type. While these component 
specific bits are managed and controlled through 'view|modify the component' 
policies, they are also part of the event data model and may be included in the 
serialized event. Because they exist outside the context of the component that 
generated it, those details are enforced through 'view the data' policy for 
that component. In the future, if you have any concerns regarding security or 
policy enforcement, please report them accordingly [1].

[1] https://nifi.apache.org/security.html

> Provenance authorization refactoring
> 
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Mark Bean
>Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with 
> Provenance queries. The 'query provenance' policy should be the only policy 
> required for viewing Provenance query results. Both 'view the component' and 
> 'view the data' policies should be used to refine the appropriate visibility 
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of 
> the graph. For example, if a user does not have 'view the component' policy, 
> the graph shows this component as a "black box" (no details such as name, 
> UUID, etc.) However, when querying Provenance, this component will show up 
> including the Component Type and the Component Name. This is in effect a 
> violation of the policy. These component details should be obscured in the 
> Provenance event displayed if user does not have the appropriate 'view the 
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user 
> performing the query belongs to the 'query provenance' global policy. As 
> mentioned above, some information about the component may be obscured 
> depending on 'view the component' policy, but the event itself should be 
> visible. Additionally, details of the event (clicking the View Details "i" 
> icon) should only be accessible if the user belongs to the 'view the data' 
> policy for the affected component. If the user is not in the appropriate 
> 'view the data' policy, a popup warning should be displayed indicating the 
> reason details are not visible with more specific detail than the current 
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph 
> should display all events. Currently, if the lineage graph includes an event 
> belonging to a component which the user does not have 'view the data', it is 
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the 
> graph should indicate the event type as long as the user is in the 'view the 
> component'. Subsequent "View Details" on the event should only be visible if 
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events 
> should be shown. Component Name and Component Type information should be 
> conditionally visible depending on the corresponding component policy 'view 
> the component' policy. Event details including Provenance event type and 
> FlowFile information should be conditionally available depending on the