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:

1. Consumer sends an access request for a resource (e.g. a Data Product's output port)
2. Resource owner, receives a notification asking to accept or reject the access request.
3. Resource owner accepts the request. the Access Request action can finish its job
4. The provisioning coordinator gets involved to coordinate the job
5. The technology adapter for that resource is invoked by the provisioning coordinator and receives all the request details
6. The marketplace plugin is invoked by the provisioning coordinator to update the Access Control List also on the witboost side
7. 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: