[
https://issues.apache.org/jira/browse/NIFI-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372759#comment-15372759
]
ASF GitHub Bot commented on NIFI-2003:
--------------------------------------
Github user mcgilman commented on a diff in the pull request:
https://github.com/apache/nifi/pull/628#discussion_r70423287
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-authorization/src/main/java/org/apache/nifi/authorization/user/StandardNiFiUser.java
---
@@ -23,18 +23,20 @@
*/
public class StandardNiFiUser implements NiFiUser {
- public static final StandardNiFiUser ANONYMOUS = new
StandardNiFiUser("anonymous");
+ public static final StandardNiFiUser ANONYMOUS = new
StandardNiFiUser("anonymous", null);
private final String identity;
private final NiFiUser chain;
+ private final String clientAddress;
- public StandardNiFiUser(String identity) {
- this(identity, null);
+ public StandardNiFiUser(String identity, String clientAddress) {
--- End diff --
Should we offer another constructor for when we don't have a client address?
> User Identity Normalization
> ---------------------------
>
> Key: NIFI-2003
> URL: https://issues.apache.org/jira/browse/NIFI-2003
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
> Reporter: Matt Gilman
> Assignee: Bryan Bende
> Fix For: 1.0.0
>
>
> NiFi allows for a number of different authentication mechanisms. Once the
> user has authenticated he/she is identified by their identity. This is a
> String that is returned by the authentication mechanism. For certificate or
> LDAP based authentication this is a DN. For Kerberos it is the user
> principal. If the same user authenticates through different mechanisms, they
> may have different identities. In 0.x this was annoying but not a big deal as
> it was just a matter of (re)assigning the user role. However, in 1.x this is
> unacceptable given the nature of fine grain authorization and the number of
> access policies that must be duplicated.
>
> Because we’ve delegated user authorization and the underlying implementation
> can choose to authenticate however they want, we cannot rely on our internal
> User/Group/Policy model to enforce any normalization.
>
> After discussions with Andy, Joe, and Bryan, I think we have a proposal that
> will provide the flexibility needed without requiring continued maintenance
> by an Administrator. Additionally, it shouldn’t require too many additional
> development cycles.
>
> The basic idea is to add configurable mappings that will run after the user
> identity determined but before any authorizations. These mappings are
> purposefully decoupled from the authentication mechanisms to reduce
> duplicative configurations and support a more flexible solution. These
> mappings could be configured in nifi.properties as follows. Here, the last
> segment of the property name is an identifier used to associate the pattern
> with the replacement value.
>
> {noformat}
> nifi.security.identity.mapping.pattern.dn=^cn=(.*?),dc=(.*?),dc=(.*?)$
> nifi.security.identity.mapping.value.dn=$1@$2.$3
> nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
> nifi.security.identity.mapping.value.kerb=$1@$2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
