[jira] [Commented] (NIFI-2003) User Identity Normalization

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ 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 <bb...@apache.org>
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)