[
https://issues.apache.org/jira/browse/NIFI-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371511#comment-15371511
]
ASF GitHub Bot commented on NIFI-2003:
--------------------------------------
GitHub user bbende opened a pull request:
https://github.com/apache/nifi/pull/628
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
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bbende/nifi NIFI-2003
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/628.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 #628
----
commit 3cd7c616474a5ae464fd00325f8361321f5c83f8
Author: Bryan Bende <[email protected]>
Date: 2016-06-16T15:51:00Z
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
----
> 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)
