Page History

...

As part of this work the REST APIs will be refactored to better align with the resources being authorized and to address confusion over the allowed content types. By mirroring the authorization resources with our REST resources we can better scale as new features and ideas are added. Taking a super granular approach to authorization could still yield a cumbersome experience for the user so we've tried to design the API and resources to best accommodate that.

Resource /flow

/flow**
/flow/about
/flow/banner
/flow/search-results**
/flow/component-listing**
/flow/status
/flow/process-groups/{id}/status
/flow/processors/{id}/status
/flow/input-ports/{id}/status
/flow/output-ports/{id}/status
/flow/remote-process-groups/{id}/status
/flow/bulletin-board**
/flow/cluster/search-results

The flow resource is the only resource that would need to be authorized for a user to load the UI.

...

Resource /controller

/controller/bulletins
/controller/config
/controller/reporting-tasks**
/controller/cluster
/controller/cluster/search-results
/controller/cluster/nodes/{id}

This approach implies that if a user has READ/WRITE to /controller then they can READ/WRITE the controller configuration and the cluster. Additionally, controller level bulletins are comprised of bulletins from reporting tasks and cluster events.

...

/process-groups/{id}
/process-groups/{id}/bulletins**
/process-groups/{id}/controller-services**
/process-groups/{id}/processors**
/process-groups/{id}/process-groups**
/process-groups/{id}/remote-process-groups**
/process-groups/{id}/connections**
/process-groups/{id}/input-ports**
/process-groups/{id}/output-ports**
/process-groups/{id}/funnels**
/process-groups/{id}/labels**
/process-groups/{id}/snippets
/process-groups/{id}/snippets/{id}
/process-groups/{id}/snippet-instance
/process-groups/{id}/templates**
/process-groups/{id}/template-instance

...

Access to the template will be handled by the closest ancestor process group with access policies if none are explicitly defined.

Resource /controller-services/{id} /controller-services/{id}

/controller-services/{id}/bulletins

Access to the controller service will be handled by the closest ancestor process group with access policies if none are explicitly defined.

Resource /input-ports/{id}

/input-ports/{id}/input-ports/{id}/bulletins

Access to the input port will be handled by the closest ancestor process group with access policies if none are explicitly defined.

Resource /output-ports/{id}

/input-ports/{id}/input-ports/{id}/bulletins

Access to the output port will be handled by the closest ancestor process group with access policies if none are explicitly defined.

...

Access to the output port will be handled by the closest ancestor process group with access policies if none are explicitly defined.

Resource /processors/{id} /processors/{id}

/processors/{id}/bulletins

Access to the processor will be handled by the closest ancestor process group with access policies if none are explicitly defined.

Resource /remote-process-groups/{id} /remote-process-groups/{id}

/remote-process-groups/{id}/bulletins
/remote-process-groups/{id}/input-ports/{id}
/remote-process-groups/{id}/output-ports/{id}

...

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:

...