Consideration: Tag-Based Access Control System for FlowFuse

## Summary

A **tag-based access control system** inspired by industrial SCADA/HMI security models (e.g., Rockwell FactoryTalk Security Codes).

Team owners define custom **capability tags** that are assigned to users and required by resources. This extends FlowFuse's granular RBAC to provide finer control over MCP servers, instances, devices, and—via an ACL Node—flows within Node-RED.

**Co-exists with RBAC** - This is an additional layer, not a replacement. Users still need appropriate RBAC roles; capabilities add granularity within allowed scope.

## Problem Space

FlowFuse's hierarchical RBAC (Owner → Member → Viewer → Dashboard) has limitations:

- **Fixed boundaries** - New access patterns require role modifications
- **All-or-nothing** - A "Member" has Member access to everything in an application
- **No cross-cutting** - Can't grant "all Line 1 resources" across multiple apps
- **Platform-level only** - Can't control access within Node-RED flows at runtime

## Proposed Concept: Two-Part System

### Part 1: FlowFuse Platform Capabilities
Team owners define capability tags (e.g., `line-1`, `maintenance`, `deploy`). Users get yes/no toggles per tag. Resources declare required tags.

### Part 2: Node-RED ACL Node (Runtime Control)
A new ACL Node checks user capabilities at runtime, enabling flow-level access control without making flows database entities:

```
[HTTP In] → [ACL Node: requires maintenance] → [Maintenance Flow]
↓ (denied)
[Access Denied Response]
```

Detailed Example

```
Team: Manufacturing
│
├── Capabilities Defined: line-1, line-2, maintenance
│
├── User Assignments:
│ ├── Operator-Line1: [line-1 ✓]
│ ├── Operator-Line2: [line-2 ✓]
│ └── Engineer: [line-1 ✓, line-2 ✓, maintenance ✓]
│
├── MCP Server Requirements:
│ ├── "Line-1-Data": requires [line-1]
│ ├── "Line-2-Data": requires [line-2]
│ └── "Maintenance-API": requires [maintenance]
│
└── Node-RED Flows (using ACL Node):
├── Dashboard Tab "Line 1": ACL requires [line-1]
└── HTTP "/maintenance/*": ACL requires [maintenance]
```

**Result:**
- Operator-Line1 → sees Line 1 dashboard, queries Line-1-Data via Expert
- Engineer → sees all dashboards, queries all MCP servers

Applicable Resources

| Resource | Control Method |
|----------|---------------|
| **MCP Servers** | Platform-level: gates Expert access |
| **Instances** | Platform-level: extends application RBAC |
| **Devices** | Platform-level: device access control |
| **Flows/Paths** | Runtime: via ACL Node in Node-RED |
| **Dashboard elements** | Runtime: via ACL Node in Node-RED |

SCADA/HMI Inspiration

Industrial systems like Rockwell FactoryTalk use "Security Codes" (A-P checkboxes):

- Users get assigned codes (A yes/no, B yes/no, etc.)
- Resources declare which codes can access them
- Fine-grained, customer-defined permissions
- Runtime access control within HMI screens

This model maps well to FlowFuse's needs for operator-level access segregation.

## Open Questions

- [ ] How do capabilities interact with application RBAC? (Additive restriction)
- [ ] UI/UX for defining and assigning capabilities
- [ ] ACL Node design and API for querying user capabilities
- [ ] Should capabilities support AND/OR logic?
- [ ] Audit logging for capability-based access decisions

## Related Issues

**Extends Granular RBAC:**
- #6477 - Application-level RBAC for MCP Servers
- #6108 - Granular RBAC follow-up

**Overlapping Tag Concepts (potential consolidation):**
- #6031 - Tag Management in FlowFuse (SCADA data tags)
- #4027 - Tags on FlowFuse Users (user attributes)

No files, tests, or entry points are named. Start by reviewing related issues #6477, #6108, #6031, and #4027, then resolve the listed questions about RBAC interaction, UI, ACL APIs, logic, and auditing. Done requires an agreed scope and acceptance criteria before implementation can begin.

Written by the indexing model from the issue text.