Allow HTTP security options to be set via device settings

[knolleary]

Description

As a: flow creator

I want to: secure http end points served by the device agent

So that: they are secured to the same standard as hosted-instances

---

We can easily provide the basic auth option as that is hardcoded into the settings file. Provided FF Team auth is trickier as it requires oauth bounce to the platform and all the bits that entails. Need to think about how to achieve that securely when the device is running outside the security boundary of the platform

Acceptance Criteria

• Able to secure dashboard/http end points served by the device

Requested By

• https://app-eu1.hubspot.com/contacts/26586079/record/0-1/8936601

[robmarcer]

As a first iteration, just being able to do this via the settings file would be valuable.

This has just been requested by - https://app-eu1.hubspot.com/contacts/26586079/record/0-2/12971827644

[knolleary]

We don't expose the settings file for the user to edit.

One quick iteration would be to allow those settings to be set via the device.yml file - the only file we let the user edit.

The bigger iteration is providing a more consistent UX in the platform UI for modifying these settings.

[robmarcer]

Using the device.yml would work in this (https://app-eu1.hubspot.com/contacts/26586079/record/0-2/12971827644) customer's case @knolleary

[joepavitt]

Duplication of: FlowFuse/flowfuse#4204

[Steve-Mcl]

@joepavitt can you clarify the task in this iteration pls?

Nick states:

One quick iteration would be to allow those settings to be set via the device.yml file - the only file we let the user edit.

and

The bigger iteration is providing a more consistent UX in the platform UI for modifying these settings.

[knolleary]

The iterations are as stated:

• First iteration (this milestone) is allowing the auth settings to be set via the device.yml file. This should be fairly self-contained and unlocks the capability quickly.
• Second iteration (which we can scope and schedule for a future milestone) will be to have an appropriate settings UI.

[Steve-Mcl]

Using the device.yml would work in this (https://app-eu1.hubspot.com/contacts/26586079/record/0-2/12971827644) customer's case

Rob, that link has no details about the request (it seems to lead only to the customer details). Can you let me know what they asked for?

I ask because from my understanding, this 1st iteration proposed would only permit setting single basic auth user in httpNodeAuth and that would then add basic security to not only the dashboard but also all HTTP Endpoints that the devices flows create via http-in ~ http-response nodes.

[Steve-Mcl]

@knolleary to clarify 1st iteration.

As this will permit user to set httpNodeAuth via device yaml, do you have thoughts on whether should this be raw or curated.

e.g. raw - take what the user enters (requires knowledge of yaml object formatting)

deviceId: xxxxxxxxxxxx
forgeURL: http://xxxxxxxxxxxxxx:3000
token: ffd_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
credentialSecret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
brokerURL: ws://[::1]:9884
brokerUsername: device:xxxxxxxx:xxxxxxxxxxxx
brokerPassword: ffbd_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
httpNodeAuth:
  user: admin
  pass: $xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

e.g. curated - specific props, not nested, forgoes yaml formatting knowledge (i.e. simplified but not an exact translation of Node-RED docs https://nodered.org/docs/user-guide/runtime/securing-node-red)

deviceId: xxxxxxxxxxxx
forgeURL: http://xxxxxxxxxxxxxx:3000
token: ffd_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
credentialSecret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
brokerURL: ws://[::1]:9884
brokerUsername: device:xxxxxxxx:xxxxxxxxxxxx
brokerPassword: ffbd_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
httpNodeAuth.user: admin
httpNodeAuth.pass: $xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Either way, I would recommend we sanity check the values and return a valid/not valid result when parsing the yaml file (as we do currently for missing values when provisioning etc)

[knolleary]

Option 1 gets my vote. Will check to see what you've put in the PR :)

httpNodeAuth:
  user: admin
  pass: $xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx