Access Control Modes

Access Control in Witboost can be implemented with different configurations. Here we present a couple of notable examples:

• Static: the output ports will grant access only to groups defined in their descriptors at provisioning time. Then, each subsequent access/revoke request is handled by adding or removing a user from a group (usually invoking a remote microservice that will interact with the Active Directory/LDAP systems). This mode configure a static access for the resources (a set of defined groups) and the accesses to users are granted outside of witboost.
• Dynamic: the grant/revoke is directly reflected to the target output ports at request time, when the request is accepted. The request is sent to the technology adapters which will take care of it. In this case witboost takes care of each new access request by invoking an API on the technology adapters to update the ACLs for the resource.

Those two modes are just examples of how an access control flow can be implemented, and configurations used for one are available also in other scenarios; in fact, these two can be used in conjunction since they are affected by two independent phases: provisioning and access request. So, we could even define another scenario where we use the static functionalities in the provisioning phase and the dynamic ones in the request phase.

The provisioning phase is the process of deploying resources. You can configure witboost to send to make the technology adapters create accesses for the groups and users while provisioning the resource (like in the static example). The users or the groups that are assigned to the resources in this way will be marked as locked.

The access/revoke phase is the process of requesting access/revoke for a group of users to a resource. The user requests access/revoke for a specific resource by using the Access Control panel (in case the user is also the resource owner) or the Marketplace components view. The request can just be sent to a third-party service, without invoking again the technology adapters (this is what happens in the static example, where the third-party service takes care of associating the users to the groups in the Active Directory/LDAP system). Another option is to send the access/revoke action to the technology adapters (like in the dynamic example) which can grant or deny access based on its own logic and rules.

Modes implementation

In Witboost, the Access Control functionality leverages Actions, in particular the Access Request Action (described in the dedicated section here).

Wether you decide to associate users and groups while provisioning a resource (what we called the "static" access control), or the technology adapters grants access at request time ("dynamic" access control), is up to the platform team to reflect this choice in the technology adapters implementation and witboost configuration.

On the Witboost side, you can tweak some configurations to match what you decided to implement for your use-case. In fact, you can decide if you want to:

• Call the /updateAcl endpoint on the technology adapters when the request is accepted
• Delegate access requests and revoke requests to an external platform
• Handle access requests with a remote hook or internally through notifications (directly inside witboost) leveraging the actionHandlers.accessRequest.hook.type configuration

All those configurations can be found under actionHandlers. Here you can change the Access Request Action configuration under actionHandlers.accessRequest. It looks like this:

actionHandlers:
  accessRequest:
    updateAclUrl: <your /updateAcl endpoint URL>
    getExecutionPlanStatusUrl: <your /getExecutionPlanStatus endpoint URL>
    invokeUpdateAcl: true
    hooks:
      - type: notificationAccessControl

In particular, with:

• invokeUpdateAcl: You can set whether the /updateAcl on the technology adapters should be called when the request is accepted. If your implementation requires to handle the access requests through technology adapters, this should be set to true.

info

When this parameter is set to true, all the parameters defined under the action input.fields are sent to the technology adapter. To learn more about this, check the section of Access Control Request Template YAML file

• hooks: You can set whether you want to handle access granting/revoking using internal notifications, delegating to an external service, or both. When you choose to bind a remoteRequest hook into the accessRequest action, you are delegating the requests to an external service (See how to configure a Remote Request hook).

To get a step-by-step guide of some example scenarios, take a look at the dedicated sections for the Simple Access Control Flow and the Delegated Access Control Flow.