...
Endpoint for other NiFi instances to obtain details required to perform site to site data transfer.
User Identity Normalization
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.
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
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...