# Communications Backbone

Communications Backbone by C2 Team (NOC)

### Data flow 

- Client A sends to `client-a-outbox` (or POSTs to API /send - not yet implemented)
- Messages are forwarded from `client-a-outbox` to `soar-publish` 
- Messages are published from `soar-publish` with the given topic read from the message 
- Subscribers listen to for messages 
- Subscription is delivered to `client-b-inbox` 
- Client B reads from `client-b-inbox (or GETs from API /receive)

There is a parallel flow when a client sends to `client-a-notify` in which case the 
messages are delivered through the broadcast exchange to all clients `client-x-inbox`.

### Auth placeholder 

As a proxy for proper authentication, when you post a client a random secret is 
returned in the response. To send to / receive from the bus you then call the API
with the client_id and secret and it checks they match. The client_id determines 
which queues it reads from. 

Subsequent requests to the client endpoint return the client_id but not the secret.

### Running via docker-compose

Using `docker-compose` will mean that everything is setup automatically, this includes the `rabbitmq` container, the backbone API, and the backbone bus. The `run-compose.sh` script has been provided to simplify this even further - all you have to do is set whatever env vars you need in the `.env` file and then run `./run-compose.sh` (the defaults in `.env` are fine for local dev work, but ones not labelled `optional` will need setting in a production setting). The env vars are:

- `DATA_DIR` - Where to mount the volume of the API container on your local system. This defaults to the result of `pwd`, which should be within the `communications-backbone` repo
- `SOAR_TOKEN_LIFETIME` (Optional) - The number of hours until a newly created token expires
- `SOAR_TOKEN_SECRET` (Optional) - A secret key used to encrypt/decrypt token data. If specified the value should be set using TokenModel.getKey()

### Running manually

#### Setup 

```
pipenv install  
```

#### RabbitMQ 

`docker run --rm -p 5672:5672 -d --hostname rmq --name rmq rabbitmq:management`

#### API 

```
pipenv run python api.py 
```

#### Create some clients 

`POST` to `http://localhost:3000/clients` 

#### Event bus 

``` 
pipenv run python soar_bus.py
```

#### Send / Receive directly 

```
# Send a message 
pipenv run python client_send.py noc-c2-outbox 'soar.noc.slocum.something' from noc-c2
```

```
# Receive messages  
pipenv run python client_read.py noc-sfmc-inbox
```

#### Receive via API

As a placeholder for proper authentication you post the `client_id` and 
`secret` and it checks that a client with that id exists and that the 
secret matches before allowing the request. 

This should be replaced with a proper auth layer. 

`GET http://localhost:5000/receive?client_id=[client_id]&secret=[secret]`

### Components 

- `soar_bus.py` - Run all the components threaded based on existing clients  
- `soar_forward.py` - Listen for messages on queue A and forward messages to queue B 
- `soar_publish.py` - Listen for messages on queue A and publish on exchange B 
- `soar_broadcast.py` - Listen for messages on queue A and broadcast on exchange B 
- `soar_subscribe.py` - Create subscriptions to both the publish and broadcast exchange - deliver to queue A
  (I think this should probably be 2 separate functions to keep things nice and simple)
- `soar_push.py` - Not yet implemented - Listen for messages on queue A and POST to the client's webhook URL