...
User interaction and design
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**
The flow resource is the only resource that would need to be authorized for a user to load the UI.
** indicates the results will be filtered according to the permissions of the user have with the resources in question. /flow will return the flow structure. If authorized for a particular resource that structure can include configuration details for a given resource. This would be equivalent to calling it’s own endpoint defined below. If not authorized the structure would only include UUID and position details.
Resource /system
/system/diagnostics
Explicit access to system diagnostics.
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.
Resource /reporting-tasks/{id}
/reporting-tasks/{id}
Access to the reporting task will be handled by the controller if none are explicitly defined.
Resource /process-groups/{id}
/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}/templates/{id}
/process-groups/{id}/template-instance
Process group level bulletins are an aggregation of bulletins of all encapsulated components. ** indicates the results will be filtered according to the permissions of the user have with the resources in question.
Access to a given process group will extend access to encapsulated components unless overridden with explicit component level access policies.
A snippet is a section of the data flow and is created using the Ids of any number of selected components. We can then use this snippet for bulk operations like delete, move, copy/paste operations and as a source of a template. Snippets are typically short lived in that they are deleted once the action has been completed. In order to create the snippet, they user will need to have WRITE access to this process group and READ access to every specified component. When the snippet is actually used, we will need to ensure that they user has WRITE access to the process group in question and has READ or WRITE access for every component in the snippet based off of what it’s being used for. No explicit access policies will be allowed for snippets due their short-lived nature.
Resource /templates/{id}
/templates/{id}
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.
Resource /funnels/{id}
/funnels/{id}
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}
Access to the remote process group will be handled by the closest ancestor process group with access policies if none are explicitly defined.
Resource /labels/{id}
/labels/{id}
Access to the label will be handled by the closest ancestor process group with access policies if none are explicitly defined.
Resource /connections/{id}
/connections/{id}
Access to the connection will be handled by the source component of that connection if no explicit access policies are defined.
Resource /flowfile-queue/{connection-id}
/flowfile-queue/{connection-id}/listing-request
/flowfile-queue/{connection-id}/drop-request
/flowfile-queue/{connection-id}/flowfiles/{id}
/flowfile-queue/{connection-id}/flowfiles/{id}/content
READ and WRITE access to the queue of a connection should be driven by WRITE access to that connection.
Resource /provenance
/provenance/event-search-request
/provenance/event-search-request/{id}
/provenance/lineage-request
/provenance/lineage-request/{id}
/provenance/events/{id}
/provenance/events/{id}/content/input
/provenance/events/{id}/content/output
User is allowed to access provenance. Event and lineage requests can be created if the user has access to /provenance. This is another retrieve and filter scenario.
Event access (and corresponding content) is driven by the component that generated it and the context (flowfile attributes). However, there may be a corner case here as we may want to be able to have explicit policies for the provenance events that differ from the access policies of the component that generated it.
Resource /site-to-site
/site-to-site
Endpoint for other NiFi instances to obtain details required to perform site to site data transfer.
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...