[
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.xxxx` 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 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)
