[
https://issues.apache.org/jira/browse/NIFI-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373054#comment-15373054
]
ASF subversion and git services commented on NIFI-2003:
-------------------------------------------------------
Commit ba763b95e8147be159a39031b9c7396e88293ebd in nifi's branch
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=ba763b9 ]
NIFI-2003 Creating abstract authentication provider and incorporating into
existing providers
NIFI-2201 Add support for seeding cluster nodes in authorizations.xml
- Passing client address along in user context on authorization requests
- This closes #628
> 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)
