A Simple Access Control Flow
Overview
In this example, we are going to show an example of how to implement the Access Control in the "dynamic" scenario.
Every time the owner of a resource accepts a grant or revoke request, a call to /updateAcl
to the technology adapter of the target technology is made to add or remove that user from the Access Control List.
You may be already familiar with this flow, as this is how witboost acts by default.
Technology Adapter implementation
We won't go deeper into how you should implement the technology adapter but general remarks is that, for this flow, each technology adapter should:
- Implement the
/updateAcl
endpoint in way that users or groups that are listed in the access/revoke requests are reflected accordingly into the target technology's Access Control List
Witboost configurations
For this scenario, we want to invoke the /updateAcl
, thus in the Access Request Action we set invokeUpdateAcl
to true
:
actionHandlers:
accessRequest:
# other configs for the Access Request Action
getExecutionPlanStatusUrl: <your /getExecutionPlanStatus endpoint URL>
invokeUpdateAcl: true
We are not done yet, since we also want to bind a third-party interaction to the accessRequest
action because we want to have an internal approval process to grant or revoke access to resources where resource owners receive an access request from consumers.
To do so we setup a hook, specifically thought for sending a notification to resource owners when there is an access request to be approved or rejected:
actionHandlers:
accessRequest:
# other configs for the Access Request Action
getExecutionPlanStatusUrl: <your /getExecutionPlanStatus endpoint URL>
invokeUpdateAcl: true
hooks:
- type: notificationAccessControl
And that's it! But what is the effect from the standpoint of the end-user?
A Simple Access Control Flow In Action
This is a step-by-step of what end users will experience:
- Consumer sends an access request for a resource (e.g. a Data Product's output port)
- Resource owner, receives a notification asking to accept or reject the access request.
- Resource owner accepts the request. the Access Request action can finish its job
- The provisioning coordinator gets involved to coordinate the job
- The technology adapter for that resource is invoked by the provisioning coordinator and receives all the request details
- The marketplace plugin is invoked by the provisioning coordinator to update the Access Control List also on the witboost side
- Resource owner and requester are informed that the grant has been effectively registered into the target technology
Step 2 is the effect of having set the notificationAccessControl
hook.
Step 4 is the effect of having set the invokeUpdateAcl
to true
.
Here is an overview of all the components that were involved: