Allow local (LAN) access to a device as a config option

[robmarcer]

Description

As a backup to being able to access a device's editor from FlowFuse, it would be helpful to be able to access the editor directly.

This has been requested by this existing customer - https://app-eu1.hubspot.com/contacts/26586079/record/0-1/503903

This will allow a user to make changes to their flow in an emergency situation where their network connection to FlowFuse is unstable or offline.

We would need to consider how the local connection to these devices is secured.

I would suggest that local access is disabled by default but can be switched on by editing the device's device.yml

[MarianRaphael]

See FlowFuse/flowfuse#2855

[robmarcer]

This has also been discussed with https://app-eu1.hubspot.com/contacts/26586079/record/0-1/4909801 & https://app-eu1.hubspot.com/contacts/26586079/record/0-1/1956

[joepavitt]

Security is managed by FF OAuth, but a strong use case here is the ability to access the editor if the device has lost network connection. Open point of discussion here is how we handle the security of the offline access use case.

[ZJvandeWeg]

My worries are around having multiple ways of achieving the same thing (editing flows) which do have different features available to them.

One of these customers linked wanted a stable URL to the editor. This issue doesn't service that request. Also, all edge cases point to the problem that we cannot both provide the service level users are used to AND be partition tolerant. cap theorem is pretty clear on that, and FlowFuse shouldn't jump through hoops to reinvent the wheel.

[knolleary]

We had another question on accessing the editor if connection to the FF Platform is currently unavailable; customer doesn't want to be locked out of their devices.

There are two scenarios:

1. user wants regular direct access to the editor with FF Auth
   • when accessing the editor they are redirected to FF Platform oauth flow (same UX as accessing a hosted instance editor directly)
2. user wants 'offline' access to the editor when connection to FF platform is not available

These two scenarios are in conflict with each other. Node-RED Auth is either OAuth, or local login. It doesn't support both at the same time.

Option A - allow user to define 'local' user for the device

• Provide an 'allow local access' option in the device settings
• When enabled, the user must set a username/password combination for that device
• That username/password will be setup on the device to allow local login

Pros

• Provides offline access to the editor in case FF is unavailable (air-gapped network, network outage etc)

Cons

• Single username; cannot associate activity with particular team member

Option B - enable FFC auth for device

• Provide a 'use FFC authentication' option in device settings
• When enabled, access to the editor will redirect to FFC for authentication

Pros

• Allows local access with knowledge of who the user is

Cons

• Requires network access to FFC at the point of login; doesn't address the offline access case

Option C - both!

Whilst Node-RED doesn't support both at the same time... it could do in the future. So we could pick A or B today, and schedule work in NR to support a hybrid auth approach, then do the other.

Proposal

I propose we go with option A - allow the user to define their own username/password via device settings. We can label this feature as 'enable offline access' - emphasis this is not intended for day-to-day use.

I'll raise a feature request on NR to support hybrid auth to at least get it recorded - whether we decide we need it or not in the future.

[Steve-Mcl]

Option A - allow user to define 'local' user for the device

• Provide an 'allow local access' option in the device settings
• When enabled, the user must set a username/password combination for that device
• That username/password will be setup on the device to allow local login

Pros

• Provides offline access to the editor in case FF is unavailable (air-gapped network, network outage etc)

Cons

• Single username; cannot associate activity with particular team member

If the device is air gapped (or unable to contact FF), then Auto Snapshots will fail.
However, it may just be the user decided to utelise the local login (and therefore Auto Snapshots would succeed)

Should we:
a) disable auto snapshots for all operations made by the local user?
b) continue to attempt auto snapshots regardless?
c) inform users on the UI for enabling Local Access that Auto Snapshots will not be (might not be) possible?

[joepavitt]

Why would auto snapshots not function for local access? We should be consistent in our functionality, so (b) is my preference.

[Steve-Mcl]

Why would auto snapshots not function for local access?

in the scenario listed above

user wants 'offline' access to the editor when connection to FF platform is not available

We should be consistent in our functionality, so (b) is my preference.

I'll take this approach. However, there will not be any snapshots (or audit events on the platforms) in these scenarios. That is something we will likely need to handle separately (caching?)

[Steve-Mcl]

@knolleary

Is it to be that users who access the device via the FF proxy (remote dev) that they will need to "login" using the local account username/password?

Because what I have found is:

• removing authAdmin.tokens function handler, accessing the editor via proxy URL results in clientside 404 error when launching device editor from FF
  • I likely need to handle something somewhere differently
• However, by leaving the authAdmin.tokens function handler in place, adding users array and disabling the editorTheme.login.button, we can still login directly via FF account (when launched from FF). and anyone accessing locally (via IP/host) are prompted for Username/Password
  • This does have a "less than desirable" effect when the user choses to logout from node-red user menu (the editor is still visible but the login box is shown above the flows) - but still workable

[knolleary]

Is it to be that users who access the device via the FF proxy (remote dev) that they will need to "login" using the local account username/password?

No. There should not be any change to how the proxy works; it is done via the tokens which bypasses the login prompt.

If local access it enabled, then you will get a login dialog when trying to access it locally.

[Steve-Mcl]

In my current implementation, I have added setup options for permitting local login access on the device settings pages.

However, it has just occurred to me that the the user may want (expect) the device yml to be delivered with these settings so that the device doesnt need to checkin to obtain the local login settings.

Is this a need right now? or a follow up task? (or wait for the feature to be requested?)

IMO, we should probably add support to the device agent NOW if we do intend on supporting this (the UI/UX can be implemented later)

[knolleary]

Spoke with Steve to discuss questions above.

1. No requirement for the platform to include these in the generated device.yml file
2. We should allow the user to hand edit device.yml to include the local user settings which then take priority over the platform setting. This allows the user to retrospectively enable local access after the device has lost connection with the platform.

[Steve-Mcl]

Verified on production:

Device settings

Device Agent after restart

Local Login

[ZJvandeWeg]

@Steve-Mcl @knolleary If the customer in question didn't have SSO enable, why are the team members not allowed to sign in with their usual credentials? This seems like a weird way to go about it.

Can we revert the merged PR @knolleary?

[Steve-Mcl]

@Steve-Mcl @knolleary If the customer in question didn't have SSO enable, why are the team members not allowed to sign in with their usual credentials?

Valid point. But I suspect the proposal above was designed so as not to export internal usernames/passwords (albeit encrypted) to the local devices settings file. Nick can likely articulate this better than me.