Skip to main content

A Delegated Access Control Flow

Overview​

In this example, we are going to show an example of how to implement the Access Control in the "static" scenario.

We want to delegate to an external service, that exists at our company, the decision whether to accept or reject an access request. Moreover, the Access Control List on the target technology is created only once, at deploy time, and removed only when an undeploy of the resource is performed. The technology adapters will create the initial set of groups, and no further updates on the Access Control List will be made at request time.

We will need to:

  • Adjust or implement the external service. According to the suggested implementation strategies below.
  • Implement the technology adapter accordingly
  • Adjust the witboost configuration

External Service implementation​

In order to configure an external service to work with Access Control requests coming from witboost, your service must be compliant with the API specification of the Remote Request hook found here.

You can adopt two implementation strategies, depending on some factors:

  1. Create a proxy service that handles witboost requests and registers them into the target service that you wish to handle the approvals/rejections of requests. This is the way to go if the external service requires complex authorization schemas, such as OAuth2. In that case, your proxy will need to handle also the authorization part.
  2. Directly enable your external service to work with witboost's access control requests if you have control over the codebase.

Technology Adapter implementation​

The Access Control List is created only once on the target technology, at provisioning time: a set of groups must be granted access to the technology and it won't change through the lifecycle of the resources.

This means that once your provisioning process ends on the technology adapter, the /provision/status endpoint will need to inform witboost about which are the groups that were granted access at provisioning time. The response should be something like:

aclInfo:
  - identity: group:resource-owners
    locked: true
  - identity: group:other-resource-owners
    locked: true

We are giving out a list of identities that have been granted access and should NOT be touched anymore, unless by undeploying the resource itself. This is why you can see that those groups will be displayed as locked: this prevents resource owners to remove those identities from the access control panel with a revoke request.

More details of this contract are described in the Technology Adapter API specification.

Witboost configurations​

For this scenario, we are not invoking /updateAcl on the technology adapters when a request is accepted, thus in the Access Request Action we set invokeUpdateAcl to false:

actionHandlers:
  accessRequest:
    # other configs for the Access Request Action
    getExecutionPlanStatusUrl: <your /getExecutionPlanStatus endpoint URL>
    invokeUpdateAcl: false

Moreover, we also want to bind a third-party interaction to the accessRequest action because we want to have a delegated approval process to grant or revoke access to resources by means of an external service. To do so we setup a hook, specifically thought for sending an HTTP request to an external service that will handle the request:

actionHandlers:
  accessRequest:
    # other configs for the Access Request Action
    getExecutionPlanStatusUrl: <your /getExecutionPlanStatus endpoint URL>
    invokeUpdateAcl: false
    hooks:
      - type: remoteRequest
        target: http://my-external-service.com/
        headers: # (optional)
          X-API-Key: <your API key, if any> # (optional)

And that's it! But what is the effect from the standpoint of the end-user?

A Delegated 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 do not receive any access request notification inside witboost. Instead, this decision could be taken on the external service, depending on how it is implemented at your company.
  3. The request is accepted on the external service. Who accepted it depends on the external service.
  4. The user gets added to the group that already has access to the resource.
  5. The external service contacts back witboost to update the status of the third-party interaction (as described by the Remote Request hook contract). the Access Request action can finish its job.
  6. This time, the provisioning coordinator is not involved, since we decided to not invoke the /updateAcl endpoint on the technology adapter. This is because, all needed operations to grant a user on a target technology has been made by the external service. In fact, just for the sake of the example, we are assuming that the external service is capable of adding/removing users to/from the group that has been granted access at provisioning time.

Step 2, 5 is the effect of having set the remoteRequest hook and its API contract. Step 6 is the effect of having set the invokeUpdateAcl to false.

Here is an overview of all the components that were involved. Notice that, in this scenario, the Provisioning Coordinator, Technology Adapter and Marketplace Plugin are only involved at provisioning time.