[ 
https://issues.apache.org/jira/browse/NIFI-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-2003:
------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

> 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)

Reply via email to