GitLab

At the moment any client can send any message. That means that say we have the request_approval > acknowledgement flow to send the plan C2 could send that acknowledgement to approve the plan but so could any other client attached to the backbone

How do we handle:

• transactional request/response between 2 parties
• ensuring that a client only sends the messages that match their role in the network

changed the description

Do we need RBAC in the client configuration options? If so who defines the roles and permissions and where do they live if the backbone is schema agnostic?

For SoAR we didn't have that concept but we did delegate that type of config to the planning_configuration message which doesn't solve the problem and kinda creates a new one.

If the client config specified the schema rather than the adapter then the client config could also specify a set of client capabilities:

{
  "client_id": "autonomy_engine",
  "role": "plaform_controller",
  "schema": "[link to backbone format tag]"
  "capabilities": {
    "send": ["mission_plan"],
    "receive": ["planning_configuration", "platform_status"]
  }
}

I guess this still contains an implicit understanding of the schema so to enforce this the backbone would have to understand the schema.

Having the backbone be schema-aware might not be a bad thing.

One of the things we could change is that the backbone adds the client-id to the header based on the authentication credentials. That would stop a client sending a message containing the wrong client-id.

Alternatively the backbone could reject a message where the client-id in the message header didn't match the token credentials - that again requires that the backbone is at least aware of the header schema.

Without understanding the messages the backbone could append some office-use-only type content saying which client had sent the message and then an adapter could say I'm willing to receive this instruction from this client.

So NOC SFMC has config that says I'm only willing to receive a send_plan acknowledgement from NOC C2. That way the permissions control is within each client application. The client applications determine what they're willing to do. On receiving an invalid instruction from the wrong source that client could send a reject acknowledgement (equivalent to a 403 response).

client_config.json

{
  "client_id": "noc-sfmc",
  "accepts": [
    {
      "message": "acknowledgement",
      "type": "send_plan",
      "from": ["noc-c2"]
    },
    {
      "message": "mission_plan",
      "from": ["ori-action-generator", "noc-c2"]
    }
  ]
}

With this approach the backbone doesn't change and the permissions only need to be implemented at the receiver end. A sender can do what they like but they'll get 403s if they act outside their role.

We'd need to think about the type classification stuff because it could be dependent on different fields in different message payloads