Was ist FabAccess? Grundkonzepte

Die Basics zu FabAccess (Server + Client + Konzepte) findest du hier!

Was ist FabAccess?
Grundkonzepte

Allgemeine Struktur
Abhängigkeiten von Ressourcen
Aktoren (Actors) und Initiatoren (Initiators)
Audit Log (Revisionsprotokoll)
Ausleihen and Transfer
Cache (Zwischenspeicher)
Cap'n Proto API
Claims, Notify und Interest (das Konzept vom "Anspruch erheben")
Federation (Föderation)
Measurements (Messwerte)
RBAC (Benutzerrollen und Berechtigungen)
Plugins
Projekte
Terminals
Externe Authentifikation
Nutzerverwaltung
Traits
URL und URN

Was ist FabAccess?

FabAccess ist ein leistungsstarkes, zentrales Zugangs- und Maschinenkontrollsystem für den automatisierten Verleih von Maschinen und Geräten (Management und Zuweisung von Ressourcen). Diese Selbstbedienungsfunktion ermöglicht es Benutzern über unsere App (Borepin) den Verleihprozess eigenständig durchzuführen, wodurch Betreuer von offenen Werkstätten ihre Aufmerksamkeit auf andere Tätigkeiten wie Ausbildung und Wissensvermittlung richten können und einen besseren Überblick behalten.

Die Anforderungen für FabAccess wurden mit Mitgliedern des Verbunds Offener Werkstätten e.V. und mit Betreibern von FabLabs an Hochschulen (Fab:UNIverse) entwickelt. Das daraus entstandene Lastenheft findet sich in unserem GitLab Projekt.

Maschinenverwaltung

Das Prinzip von FabAccess ist es, Maschinen über den Stromanschluss ein- und auszuschalten. So sind Maschinen im Normalfall stromlos und damit ungefährlich. Erst, wenn Nutzer an der Maschine sind, die für die sichere Bedienung befähigt und eingewiesen sind, wird die Maschine mit dem Stromnetz verbunden.

Wir wollen dabei die Idee von Neil Gershenfeld, dass Nutzer selbstständig den Umgang mit Maschinen lernen, mit den Anforderungen von offenen Werkstätten kombinieren, sodass Nutzer sich dabei nicht verletzen. Folglich benötigen Nutzer für gefährliche Maschinen idealerweise eine Einweisung - dieses Prinzip wird dann im Berechtigungssystem abgebildet.

Noch nicht unterstützt, aber geplant: Die Abnahme von Maschinen, die eine Reinigung nach Gebrauch benötigen. So wird die Nutzbarkeit von Maschinen für den nächsten Nutzer sichergestellt und der Verschleiß verringert.

Noch nicht unterstützt, aber geplant: das Reservieren von Maschinen, wollen aber keine Zeitplanung für die Nutzer übernehmen. Daher ist der Kompromiss, den wir umsetzten, dass Nutzer Maschine nur beispielsweise eine halbe Stunde reservieren können, um so den Weg zum FabLab sich keine Sorgen darüber machen müssen, dass jemand anderes in der Zeit die Maschine für 5 Stunden verwendet.

Berechtigungsverwaltung

Ein zentraler Aspekt von FabAccess ist also das Management von Berechtigungen, das die Steuerung des Zugriffs auf bestimmte Ressourcen ermöglicht. Diese Berechtigungen bieten eine feingranulare Kontrolle darüber, welcher Benutzer auf welche Ressourcen zugreifen kann, und dienen als wichtiges Instrument für die Sicherheit und Effizienz des Systems. Mit FabAccess soll der Zugriff auf Maschinen in Offenen Werkstätten verwaltet werden, um so Unfälle zu vermeiden. Auch der Zugang zu Räumen und Schränken kann organisiert werden.

Ein Anwendungsbeispiel: Die Kreissäge soll nur von denjenigen Personen angeschaltet werden können, die eine Einführung besucht haben. Nach der Einführung bekommen die Teilnehmer*innen über ihre Chip-Karte die Berechtigung für die Aktivierung der Kreissäge. Nur wer diese Berechtigung hat, kann die Kreissäge mit Hilfe der Chip-Karte einschalten.

API und Audit Log

Mit seiner flexiblen API können Ressourcenbesitz und -zustände effektiv abgebildet werden, wobei jede Ressource einem bestimmten Benutzer zugeordnet werden kann. Darüber hinaus bietet es die Möglichkeit, Statusänderungen von Ressourcen zu verfolgen, was eine präzise Überwachung und Verwaltung ermöglicht (Audit Log).

On-premise Ansatz

FabAccess ist ausschließlich selbst gehosted! Es gibt keinen Dienstleister dafür. Jeder Space soll seine eigene Infrastruktur damit abbilden und verwalten können.

Modularität per Plugins und Scripts

Die Modularität von FabAccess ermöglicht eine vollständige Anpassung an die Anforderungen unterschiedlicher Spaces. Der Ausleihprozess ist in unserem Server (BFFH) modelliert, und die Ansteuerung der Maschinen erfolgt über Plugins. Zudem bietet FabAccess die Möglichkeit, eigene Skripte über die API anzubinden, um eine höhere Automatisierung zu erreichen. Diese Vielseitigkeit eröffnet nicht nur die effiziente Nutzung von Maschinen und Geräten, sondern bietet auch Raum für Flexibilität und Anpassungsfähigkeit an die individuellen Bedürfnisse verschiedener Umgebungen

Schreibweise

Die richtige Schreibweise von FabAccess ist "FabAccess", nicht "Fab Access", nicht "Fab-Access" und nicht "Fab:Access"

Ein Maschinenzugangssystem für offene Werkstätten. Das klingt einfach, oder? Hier 1 Bit setzen, Maschine an! 1 Bit zurücksetzen, Maschine aus! Fertig. Leider stellt sich heraus, dass es nicht ganz so einfach ist. Warum brauchen wir das trotzdem?

Es gibt 2 Arten von Maschinen:

die, die Menschen verletzen
alle anderen

Es gibt 2 Arten von Werkstattnutzern:

die, die aufräumen
alle anderen

Wenn wir mit alledem klarkommen wollen, dann viel Spaß! Oder nutze FabAccess!

Warum ist es nicht so einfach? Weil es verschiedene Hürden bzw. Aspekte gibt, die dafür Berücksichtigung finden sollten:

Rollenbasierter Zugriff
Föderation
Arbeitssicherheit
IT-Sicherheit
attributgesteuerter Zugriff
Stabilität
Einfachheit der Installation
Modularität
verschiedene Maschinen
Zugänglichkeit
Zeit & Geld
verschiedene Werkstätten
komplexe Aktivierungsschemata

Wir wollen (und brauchen) viel mehr als ein "funktioniert für mich" Tool.

Perspektiven

Für die Werkstattleiter sollte das System ...

einen sicheren Betrieb garantieren
soziale Verhaltensrichtlinien etablieren bzw. erzwingen
... und ...
einfach installierbar und konfiguerbar sein
stabil in laufender Benutzung agieren
Wartungsaufwand mit wenig bis keinem Aufwand

.... es sollte sich der Werkstatt anpassen, nicht die Werkstatt an FabAccess

Für die Werkstattbenutzer sollte das System ...

einfach zugänglich sein
schnell und einfach zu nutzen sein
den Aufwand reduzieren

Einfachheit in Installation und Konfiguration

Die Installation von FabAccess wird aktiv dokumentiert
Die Konfguration erfolgt über dhall / toml Dateien
- eine GUI für das Erstellen von Konfigurationen ist wünschenswert
- die Dateien sollten gut dokumentiert sein - und du fasst sie nur einmal an
Das Anbinden neuer Maschinen ist einfach über Python, Bash, etc.
- eine wachsende Zahl von Beispielen finden sich auf GitLab, Github und anderen Plattformen

Wartung

abwärtskompatible Konfiguration und API ab Version 1.0
strukturierte Log-Dateien von Ereignissen

Zugänglichkeit

Die mobile App ist in den meisten App Stores zu finden (inkl. F-Droid)
eine APK ist frei zugänglich

Benutzung

Sensible Benachrichtigungen per OLED / e-Ink Display
Föderation

Aufwand / Nutzungsbeschleunigung

Maschinen können mit NFC Karten aktiviert werden

Unterstützte Hardware

Out of the box

DESfire EV2
- FabReader
Shelly Plugs (v1 und v2)
Rasberry Pi / LXC Container / Proxmox

Einfach erweiterbar

Python, Bash, alles, was Cap'n Proto anspricht

Probleme:

jede Werkstatt, jede Maschine ist anders. Deshalb gibt es so viele Varianten, dass es nur einen generischen Ansatz geben kannn, wenn es ein Tool für alle oder viele von uns werden soll

Zweck der API

Anbindung für Leute, die keine Core-Coder sind
nicht jeder hat ein smartphone und in nicht jedem fall macht es sinn!

Fragen aus den Reihen:

did you guys think about interoperation already existing systems like 3id?
how do you stop the people from unplugging plugs from the machine to switch on/off -> hier ist es eine Frage zwischen technischen UND sozialen Fragestellungen! wie man bestrafen kann: der letzte gemeldete Nutzer im System muss sich rechtfertigen, was passiert ist (Log File) -> log parsing ist nicht mehr im Scope von FabAccess
do you have the possbility to get the signal from the machine to check if its working? -> it depends! the core of FabAccess is switching on/off. we do not need MQTT data, but we CAN use it to make even more with it
fabaccess soll kein ERP System sein und es dient auch nicht primär zur Abrechnung von Maschinen

Was ist es nicht?

FabAccess ist kein System zum Lösen sozialer Probleme, z.B. wenn Nutzer in Spaces Maschinen unzweckmäßig verwenden! FabAccess dient lediglich dazu, Maschinen zu schalten und bei der Auswertung und Orginisation zu helfen. Vertrauen und Umgang muss trotzdem von Mensch zu Mensch geschaffen werden!

Grundkonzepte

Ein Einstieg in die Grundkonzepte von FabAccess.

Die Anforderungen an FabAccess sind im Laufe der Jahre rasant gewachsen. Ursprünglich sollte nur eine Drehbank mit Strom versorgt werden, nun können jedoch auch Türen oder Schließfächer verwaltet werden. Um diesen vielfältigen Anforderungen gerecht zu werden, haben wir einige Konzepte erarbeitet, mit denen wir den Prozess zum Freischalten dieser Ressourcen vereinheitlichen und für alle verfügbar machen wollen.

Bitte beachte: noch nicht alle hier festgehaltenen Grundkonzepte sind in FabAccess implementiert. Hier bedarf es Entwicklerearbeit.

Die Implementierungen von FabAccess resultieren aus den Konzepten. Dabei müssen oft weitere Annahmen getroffen werden, wie genau die Implementierung aussehen soll. Für all diese Fälle werden hier die Entscheidungen festgehalten und möglichst nachvollziehbar erklärt, warum die Entscheidung so getroffen wurde.

Die hier aufgelisteten Konzepte haben viel mit Softwareimplementierung zu tun. Deshalb verwenden wir in den Titeln englische Begriffe, erläutern aber an geeigneten Stellen die deutsche Interpretation.

Grundkonzepte

Allgemeine Struktur

Strukturdiagramm von Joseph Langosch, Stand 27.05.2021, es zeigt die grundlegenden Komponenten und deren Interaktionen

Grundkonzepte

Abhängigkeiten von Ressourcen

FabAccess unterstützt die Verwaltung von Ressourcenabhängigkeiten. Dabei werden automatisch Claims auf Ressourcen an die Nutzer vergeben, die eine Ressource beanspruchen, die von einer anderen abhängt.

Die abhängige Ressource kann zusammen mit der anderen Ressource zurückgegeben werden. Auch die Zustände der Traits werden bei abhängigen Ressourcen berücksichtigt. Auf diese Weise kann verhindert werden, dass Ressourcen wie Absaugungen oder Kühlungen ausgeschaltet werden, wenn die Ressource, die diese benötigt, noch aktiv ist.

Grundkonzepte

Aktoren (Actors) und Initiatoren (Initiators)

Um FabAccess erweiterbar zu halten, basiert die Steuerung externer Geräte wie Wifi-Schaltsteckdosen oder Türschlössern auf einem Aktoren- und Initiatorenkonzept.

Aktoren (Actors)

Aktoren in FabAccess haben die Aufgabe, die digitalen Zustände von Ressourcen in reale Zustände umzusetzen. Vom Server aus werden die Übergänge der Traits (Eigenschaften) an kleine Skripte oder Prozesse weitergegeben, die entsprechend darauf reagieren. Aktoren erhalten vom Server Mitteilungen über Änderungen an Maschinen, beispielsweise wenn eine Maschine ausgeliehen wird, und passen dann den realen Zustand der Maschine an. Dadurch wird die Maschine für Nutzer freigeschaltet. Darüber hinaus ermöglichen Aktoren die Steuerung zusätzlicher Anzeigen wie Maschinenampeln oder Displays. Aktoren werden an Maschinen gebunden.

Initiatoren (Initiators)

Mit Initiatoren werden reale Zustände auf die digitalen Zustände in FabAccess abgebildet. Initiatoren sind Plugins, die den Status einer Maschine aktiv verändern können. Initiatoren werden an Maschinen gebunden. Dies ermöglicht beispielsweise die automatische Rückgabe von Maschinen, wenn sie nicht verwendet werden, das Festlegen von Zeitschaltungen oder Türkontakte, die den aktuellen Zustand der Tür übertragen können, und FabAccess kann entsprechend darauf reagieren.

Wie wird das genutzt?

Das Einbinden von Aktoren und Initiatoren geschieht in der Hauptkonfiguration bffh.dhall.

Eine Sammlung von Initiatoren und Aktoren ist hier zu finden.

Grundkonzepte

Audit Log (Revisionsprotokoll)

Interaktionen und Ergebnisse der Verwendung von Ressourcen werden protokolliert, um sie später auswerten zu können - zum Beispiel im Fehlerfall, in der Schadensaufklärung oder für die Abrechnung der Nutzung (Nutzungsgebühren).

Über das Audit Log File

Das Audit-Log leitet alle Änderungen an Maschinen vom Server aus weiter. Ein Plugin kann diese Informationen nutzen, um Abrechnungen zu erstellen oder Maschinenzeiten grafisch auszuwerten. Diese Funktion bietet auch Möglichkeiten für eine detaillierte Analyse und Optimierung der Maschinennutzung.
Als zusätzliche Option können eigene Prozesse an die API gebunden werden. Diese ermöglichen einen direkten Zugriff auf die Funktionen des Servers über die API und eröffnen die Möglichkeit für Massenänderungen oder die zeitgesteuerte Zuweisung von Rollen.

Beim Erzeugen von Vorratsdaten ist stets dabei darauf zu achten, nur die minimal notwendigen Daten zu speichern und auszuwerten, um die Privatsphäre der Nutzer zu schützen und das Vertrauen nicht zu verletzen. FabAccess ist hier sehr sparsam und schreibt generisch je Ereignis eine Zeile im JSON-Format. Der Zeitstempel ist dabei im Unix-Format:

{"timestamp":<UNIX Zeitstempel>,"machine":"Maschinen-ID","state":"<Status> <Benutzer>"}

Bffh protokolliert Zustandsänderungen in der Audit-Log-Datei (der Pfad wird über auditlog_path in der Konfigurationsdatei (*.dhall) festgelegt). Ausschnitt einer Beispiel Log File:

{"timestamp":1726239904,"machine":"Fokoos","state":"inuse local_lab_admin"}
{"timestamp":1726239905,"machine":"Fokoos","state":"free"}
{"timestamp":1726239932,"machine":"Ender","state":"inuse local_lab_admin"}
{"timestamp":1726239933,"machine":"Ender","state":"free"}
{"timestamp":1726240081,"machine":"Ender","state":"inuse local_lab_admin"}
{"timestamp":1726240088,"machine":"Ender","state":"free"}
{"timestamp":1726240112,"machine":"Mjolnir","state":"inuse local_lab_admin"}
{"timestamp":1726240122,"machine":"Mjolnir","state":"disabled"}
{"timestamp":1726240125,"machine":"Mjolnir","state":"disabled"}
{"timestamp":1726240126,"machine":"Mjolnir","state":"blocked local_lab_admin"}
{"timestamp":1726240128,"machine":"Mjolnir","state":"free"}
{"timestamp":1726240132,"machine":"Mjolnir","state":"inuse local_lab_admin"}
{"timestamp":1726240134,"machine":"Mjolnir","state":"free"}
{"timestamp":1726240139,"machine":"BashMachine","state":"inuse local_lab_admin"}
{"timestamp":1726240141,"machine":"BashMachine","state":"free"}

Parsing mit JQ

sudo apt install jq

Allgemeines Parsen

jq . /opt/fabinfra/bffh-data/bffh.audit

{
  "timestamp": 1727110784,
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}
{
  "timestamp": 1729189184,
  "machine": "Mjolnir",
  "state": "free"
}
{
  "timestamp": 1729189186,
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}

UTC Timestamps

Parsen mit allgemeingültiger UTC-Zeitstempelformatierung:

{
  "timestamp": "2024-09-23T18:59:44 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}
{
  "timestamp": "2024-10-17T20:19:44 CET",
  "machine": "Mjolnir",
  "state": "free"
}
{
  "timestamp": "2024-10-17T20:19:46 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}

Mit lokaler Zeitzone

Oder zum Beispiel mit der Zeitzone Europe/Berlin:

TZ=Europe/Berlin jq '.|.timestamp |= strflocaltime("%Y-%m-%dT%H:%M:%S %Z")' /opt/fabinfra/bffh-data/bffh.audit

{
  "timestamp": "2024-09-23T18:59:44 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}
{
  "timestamp": "2024-10-17T20:19:44 CET",
  "machine": "Mjolnir",
  "state": "free"
}
{
  "timestamp": "2024-10-17T20:19:46 CET",
  "machine": "Mjolnir",
  "state": "inuse local_lab_admin"
}

oder noch lesbarer durch Umstellen des Formats:

TZ=Europe/Berlin jq '.|.timestamp |= strflocaltime("%d.%m.%Y %H:%M:%S Uhr")' /opt/fabinfra/bffh-data/bffh.audit

{
  "timestamp": "08.12.2024 00:57:27 Uhr",
  "machine": "zam-raum1-ecke8-macgyver",
  "state": "free"
}
{
  "timestamp": "08.12.2024 00:57:29 Uhr",
  "machine": "zam-raum1-ecke8-macgyver",
  "state": "inuse Admin"
}
{
  "timestamp": "08.12.2024 00:57:30 Uhr",
  "machine": "zam-raum1-ecke8-macgyver",
  "state": "free"
}

Zum Parsen und Patterns testen empfehlen wir das Online-Tool https://jqplay.org

Grundkonzepte

Ausleihen and Transfer

Um die soziale Interaktion im Space zu fördern, ermöglicht FabAccess das Weitergeben von Claims. Benutzer können somit Ressourcen direkt an andere Benutzer weitergeben oder diese zum Zwecke der Ausbildung an andere Benutzer verleihen (englisch: "lending").

Durch diese Funktion kann die soziale Interaktion über FabAccess nachverfolgt und unterstützt werden.

Grundkonzepte

Cache (Zwischenspeicher)

In FabAccess gibt es eine Unterscheidung zwischen statischen und dynamischen Daten, die von Ressourcen besessen werden.

Dynamische Daten umfassen Zustände oder Messwerte, die von Ressourcen erzeugt werden.

Statische Daten hingegen sind Eigenschaften, die sich nicht regelmäßig ändern, sondern nur in größeren zeitlichen Abständen. Diese statischen Daten werden in FabAccess zwischengespeichert, um die Antwortzeiten des Servers zu reduzieren und Ressourcen in Clients schneller anzeigen zu können.

Grundkonzepte

Cap'n Proto API

Die API von FabAccess basiert auf Cap'n Proto. Cap'n Proto wird verwendet, um eine erweiterbare und bidirektionale API bereitzustellen. Dank der Codegenerierungsfunktion von Cap'n Proto kann die API in jede Programmiersprache portiert werden. Jedes Interface wird in einer übersichtlichen Schema-Sprache dargestellt, was die API selbst dokumentierend macht. Die Verfügbarkeit von Interfaces im Client kann durch einfache Null-Checks überprüft werden.

Authentifizierung

Um einen übergeordneten Zugangspunkt zu bieten, ist die API in Systeme unterteilt, die erweitert und ausgetauscht werden können. Der Einstiegspunkt in die API ist das Bootstrap-Interface, das jedem Client angeboten wird. Nach der Authentifizierung werden die für den Client relevanten Interfaces bereitgestellt.

Scripting

Die API soll anderen Clients oder Skripten einen stabilen Zugang zu Ressourcen ermöglichen und die Zusammenarbeit zwischen Systemen fördern. Der Server entscheidet selbst, welche Ressourcen und Interfaces er den Clients zur Verfügung stellt, je nach Berechtigung und Konfiguration. Die Clients müssen daher in der Lage sein, damit umzugehen.

Ressourcenzugang

Durch die API und die damit verbundenen Anforderungen soll der Zugang zu Ressourcen für alle erleichtert und die Zusammenarbeit gefördert werden. Diese Grundlagen sollen dazu beitragen, ein föderiertes System für den Ressourcenverleih aufzubauen.

Details zu Cap'n Proto finden sich auf deren Homepage: https://capnproto.org und https://github.com/capnproto/capnproto

Warum gibt es keine REST API?

Der einfachste Punkt, weswegen REST eher ungeeignet ist der, dass unsere Verbindung bidirektional ist, also beide Seiten zu jedem Zeitpunkt Daten an die jeweils andere schreiben können. Das würde WebRTC prinzipiell problemlos ermöglichen (Datenaustausch z.B. per JSON), aber eine einfache TCP- oder QUIC-Verbindung ebenso und mit wesentlich weniger Setupaufwand. Sobald es um WebRTC geht, sind in einem webbasierten Client große Mengen angepasster JavaScript-Code nötig. Ist das der Fall, könnten diese TCP-/QUIC-Verbindungen über Websockets tunneln und die bestehende Cap'n Proto API ansprechen.

Cap'n Proto API ansprechen

Eine Übersicht über verschiedene Sprachen: https://capnproto.org/otherlang.html

Grundkonzepte

Claims, Notify und Interest (das Konzept vom "Anspruch erheben")

Das Konzept von Claims dient als Abstraktion des Verleihens einer Ressource in FabAccess. Ihr Hauptzweck besteht darin, die Möglichkeiten zu verwalten, wie Benutzer Zugriff auf eine Ressource erhalten und diesen Zugriff untereinander teilen können bzw. wie Maschinen voneinander abhängig gemacht werden. Sie vereinfachen den Ausleihprozess für den Space und dessen Nutzer. Claims enthalten sog. "Interests" und "Notifies".

Zum Beispiel kann konfiguriert werden, dass eine Bandsäge nur angeschalten werden kann, wenn auch die Absaugung an ist oder der Laserschneider nur einschaltbar ist, wenn die Kühlung aktiv ist.

Claim (Anspruch erheben)

Ein "Claim" in FabAccess repräsentiert den gewährten Zugriff auf eine Ressource.

Die Flexibilität von Claims ermöglicht es, verschiedene Szenarien des Ressourcenzugriffs effektiv zu unterstützen. Zum Beispiel können mehrere Benutzer gleichzeitig einen Claim für eine Ressource erhalten, was besonders in Umgebungen mit kollaborativem Arbeiten von Vorteil ist. Darüber hinaus bietet die Möglichkeit, sich in eine Warteschlange mit einem Interest einzutragen, eine praktische Lösung für Situationen, in denen die Verfügbarkeit einer Ressource begrenzt ist und Benutzer darauf warten müssen, darauf zugreifen zu können.

in weiterer wichtiger Aspekt von Claims ist ihre Fähigkeit, Ressourcen zwischen Benutzern zu transferieren oder auszuleihen. Diese Funktionen ermöglichen eine flexible Nutzung der Ressourcen und fördern die Zusammenarbeit zwischen den Benutzern. Zum Beispiel kann ein Benutzer, der eine Ressource nicht mehr benötigt, diese einem anderen Benutzer übertragen, der sie gerade benötigt, oder ein Ausbilder kann einem Auszubildenden vorübergehend Zugriff auf eine Ressource gewähren, um bestimmte Fähigkeiten zu erlernen.

Interest (Interesse anmelden)

Ein wichtiger Bestandteil des Claims-Konzepts sind "Interests", die Reservierungen abbilden, die entweder zeitbasiert oder auf einer Warteschlange basieren können. Diese Interessen bieten den Benutzern die Möglichkeit, einen zukünftigen Zugriff auf eine Ressource zu sichern, entweder basierend auf einer vordefinierten Zeit oder in der Reihenfolge des Eintritts in die Warteschlange.

Mit einem Interest signalisiert der Nutzer dem System sein Interesse an einer bestimmten Ressource. Bei der nächsten Gelegenheit erhält der Nutzer entweder einen Claim auf die Ressource oder hat die Möglichkeit, seinen Interest auf einen Claim zu aktualisieren. Diese Flexibilität ermöglicht es den Benutzern, ihre Bedürfnisse anzupassen und auf Änderungen in der Verfügbarkeit der Ressourcen zu reagieren.

Notify (Benachrichtigen)

Das letzte Element des Claims-Konzepts ist der "Notify". Durch den Notify können Nutzer den Status einer Ressource einsehen und sich über Änderungen benachrichtigen lassen.

Der Notify ermöglicht es Benutzern, den aktuellen Zustand einer Ressource abzurufen und bei Bedarf auf Änderungen zu reagieren. Dies bietet eine wichtige Möglichkeit, den Zustand von Ressourcen zu überwachen und zeitnah auf relevante Ereignisse zu reagieren.

Durch die Möglichkeit, sich für Benachrichtigungen über Zustandsänderungen zu registrieren, können Benutzer effektiv mit den Ressourcen interagieren und sicherstellen, dass sie stets über wichtige Entwicklungen informiert sind.

Grundkonzepte

Federation (Föderation)

FabAccess ist als selbstständiges selbstgehostetes System für jeden Space gedacht, so können die Spaces selber über das komplette System verfügen und es eigenständig bis in kleinste Detail konfigurieren. Um die Zusammenarbeit von Spaces zu ermöglichen und zu fördern, können die einzelnen FabAccess Instanzen (BFFH) mit einander föderieren. Dadurch können Nutzer zwischen diesen Spaces mit verringertem Verwaltungsaufwand hin und her wechseln. Wir wollen so die Spezialisierung von Spaces ermöglichen, ohne dass Nutzer die Vorteile eines vollausgestatten Spaces verlieren. Auch kleineren Spaces wird so der Einstieg vereinfacht.

Föderation ist dabei als aktive Zusammenarbeit erdacht, also müssen sich die Betreiber dieser Spaces dazu entscheiden zu föderieren. Jeder Space kann so den Partner für die Föderation selber wählen.

Der FabAccess Client Borepin ist bereits insofern für Föderation ausgelegt, als dass er mehrere Serveradressen und Benutzer speichern kann. So ist ein Wechsel zwischen verschiedenen Spaces und/oder Nutzermodellen praktisch möglich.

Vorteile und Ziele der Föderation

beliebiger Wechsel der Nutzer verschiedener Spaces trotz technisch getrennter FabAccess-Instanzen
Zusammenarbeit von Spaces unterstützen - durch Teilen von Berechtigungen ihrer Nutzerschaften
FabAccess verbreiten, ähnlich wie das Matrix Chat-Protokoll dies mit Kommunikation macht
kann langfristig dabei helfen, Maschinendokumentationen und Maschineneinweisungen (Maschinenführerscheinen) zu vereinheitlichen
Spart NFC Karten (FabCards) ein, denn die Karten können dann in alle föderierten Spaces genutzt werden
Mit Föderation is theoretisch auch das Bilden von standortübergreifenden Clustern möglich, also eine Art Filialbildung (das ist ein wertungsfreier Fakt)
ist dabei als aktive Zusammenarbeit erdacht: die Betreiber der Spaces können sich selbst entscheiden, ob sie föderieren wollen. Föderation ist also immer optional und kann zudem jederzeit wieder deaktiviert werden

Modi oder Stufen der Föderation

Die folgenden Stufen bauen aufeinander auf, so können sich Betreiber einfacher an eine Föderation wagen und die Vorteile mit jeder Stufe erfahren.

1. Stufe (Authentifizierung: Teilen von Nutzern)

- Nutzer aus anderen Spaces können ihre FabCard auch in deinem Space verwenden
- Die Nutzer sind auch in deinem Space registriert
- Der föderierte Space übernimmt die Authentifizierung für den anderen Nutzer (wie bei SSO)

Unter dem Teilen von Nutzern verstehen wir, dass Nutzer von Space B bei dir im Space A sich mit der FabCard aus Space B authentifizieren können. Um bei dir im Space A die Maschinen nutzen zu dürfen, müssen die Nutzer aus Space B sich bei dir anmelden und deinen Nutzungsvertrag ausfüllen. Da die Nutzer aus Space B FabAccess schon kennen, werden Sie sich selbstständig registrieren und du musst nur nach einer kurzen Prüfung der Daten diese Nutzer akzeptieren. Dabei erhältst du immer die Kontaktdaten deiner Nutzer und bist nicht auf die Nutzerdaten des anderen Spaces angewiesen, sollte bei dir mal ein Unfall passieren. Die Authentifizierung der Nutzer übernimmt dann die BFFH Instanz des Space B. Um nicht immer mit jedem Space sofort aktiv föderieren zu müssen, ermöglichen wir es dir auch das Teilen von Nutzern für unbekannte Spaces zu erlauben. So kannst du nach einer aktiven Föderation mit dem anderen Space gleich die Nutzerdaten übernehmen, um so nicht noch mal alle Nutzer anzupassen. Bei einer Föderation sind nämlich die IDs der Nutzer in den beiden Spaces gleich und ermöglichen den nächsten Schritt in der Föderation.

2. Stufe (1. Stufe ergänzt um Teilen von Berechtigungen)

- Nutzer aus anderen Spaces können ihre FabCard und ihre Gruppen auch in deinem Space verwenden
- Die Nutzer sind auch in deinem Space registriert
- die Gruppen des anderen Space können in deinem Space verwendet werden, wenn zum Beispiel die gleichen Maschinen im Besitz sind. Das spart Zeit bei der Einweisung und der Dokumentation.

Nach dem das Teilen von Nutzern erfolgt ist und du sich mit dem Betreiber des Space B gut verstehst, stellt ihr beide fest, dass ihr einige gleiche Maschinen in euren Spaces besitzt. Da du dem Betreiber von Space B auch bei den Einweisungen von den Maschinen vertraust, könnt ihr in der 2. Stufe auch Berechtigungen teilen. Somit müssen Nutzer von Space B, die bei dir die gleiche Maschine wie im Space B verwenden wollen, von dir nicht noch mal eingewiesen werden. Das spart Zeit bei dir und bei den Nutzern von Space B. Du behältst dabei die Kontrolle, welche Gruppen von Space B bei dir im Space A welche Maschinen nutzen können, somit kannst du dir sicher sein, dass die Nutzer wirklich eingewiesen sind.

3. Stufe (2. Stufe ergänzt um Teilen von Abrechnungen)

- Nutzer aus anderen Spaces können ihre Karte und ihre Gruppen auch in deinem Space verwenden
- Die Abrechung für diese Nutzter übernimmt dabei der andere Space für deinen Space. Über beispielsweise monatlich gesammelte Differenzrechnungen kann gegen den andere Spacecs abgerechnet werden. Das spart Zeit bei der Buchführung und die Nutzer können auch Ihre Rechnungen besser im Blick behalten.

Das Teilen von Abrechnungen stellt die letzte Stufe der Föderierbarkeit da. Da wir uns bei dem Thema noch nicht vollständig sicher sind, inwieweit das umgesetzt werden kann, steht es noch in Klammern. Die Idee zu der Föderation ist, dass Nutzer von Space B, die bei dir eine kostenpflichtige Maschine nutzen, ihre Abrechnung von Space B erhalten und nicht von dir. Das Geld der Nutzer von Space B kannst du dann mit dem Betreiber von Space B zum Beispiel monatlich verrechnen. Der Vorteil für den Nutzer liegt dabei darin, dass sie nicht bei jedem Space ihre Abrechnung machen müssen, sondern gesammelt bezahlen können.

Wie sicher ist Föderation?

Föderation benötigt Vertrauen, jedoch möchten wir nicht, dass dieses Vertrauen einfach missbraucht werden kann. Daher ist der oben beschriebene Ansatz, dass du jeden deiner Nutzer auch kennst.

Sicherheit des Servers

Für den Austausch von Benutzern und Berechtigungen ist ein sicherer Datenaustausch über das Internet notwendig. Das bedeutet auch, dass ein Dienst Ziel eines Angriffs von außen sein kann. Sobald der Dienst auf einem geöffneten Port lauscht, muss sichergestellt sein, dass nur authorisierte Server bzw. Personen darauf Zugriff haben und keinen Missbrauch begehen. Daraus ergeben sich verschiedene Fragen und Anforderungen, wie zum Beispiel

erfolgt der Informationsaustausch zwischen den föderierenden Servern auf dem gleichen Port oder gibt es hierfür z.B. eine https-verfügbare API (z.B. REST, Json, XML RPC, ...)?
wie wird das Verhalten gemonitored und Schadverhalten abgewehrt (z.B. Greylisting, Blacklisting, DDoS Vermeidung, Bruteforce-Login Attacken, Fail2Ban Jails, Firewall-Regeln...)
welche APIs sind unterinander kompatibel? Nicht jeder Space wird schnell genug seinen Server auf die aktuelle Version updaten können
Wie isolieren wir den FabAccess-Server ausreichend gegen Angriffe von außerhalb? Immerhin hat bffh Zugriff auf physische Geräte durch das Schalten von Strom an Aktoren

Sicherheit von FabFire Karten

Um die Authentifizierung sicher zu gestalten, haben wir uns für die etwas teureren NXP MIFARE DESFire EV2 Karten entschieden (ca. 1-5 € pro Karte bzw. Tag). Diese haben den Vorteil, dass sie ein Ende-zu-Ende (E2EE) Verfahren unterstützen und bisher als ungehacked gelten. Somit musst Du nicht die Schlüssel deiner Karten an jeden Reader in einem anderen Space verteilen, sondern deine BFFH Instanz kommuniziert verschlüsselt direkt mit der Karte. Auf den FabCards befinden sich auch keine Informationen der Nutzer, sondern nur der DNS-Eintrag deines Space sowie eine pseudonymisierte Nutzer ID. Somit wollen wir die technische Seite der Föderation absichern und eine Zusammenarbeit möglichst einfach gestalten.

Die Anforderungen an ein föderierbar einsetzbares SmartCard-System sind hoch, da so die jeweils andere Partei keine einfache Validierung der Karte durchführen kann. Auch das Authentifizieren mit einem Schlüssel gestaltet sich über Föderationen hinweg schwierig, da der Reader dem einen Space gehört und die Karte dem anderen. Ein Reader hat daher nicht immer die Schlüssel für die gelesenen Karten. Die DESFire-Karte besitzt ein Feature, mit dem eine Karte via OTA-Verfahren (Over-the-Air) direkt mit einem entfernten Server kommunizieren kann, ohne dass der Reader Schlüssel für die Karte benötigt. Der Reader übernimmt dabei nur die Rolle eines Proxys (Brücke/Vermittler). Mit diesem Ansatz stellen wir ein sicher föderierbares Kartensystem, was wir so bisher noch nicht im OpenSource-Bereich finden konnten.

Fragen und Ansprüche an Föderation und potentielle Probleme

muss stabil sein
es muss sicher sein (siehe oben)
Benutzer und Berechtigungen anderer Spaces können sich ändern. Nutzer könnten dem Space nicht mehr angehören. Wie halten wir den Informationsstamm ausreichend aktuell?
es müssen verschiedene Server-/API-Versionen interoperabel funktionieren
es braucht eine Whitelist bzw. ggf. sogar Blacklist für alle Spaces, die für FabAccess nutzbar sein sollen
Vertrags-, Datenschutz- und Haftungsfragen: ist die Übertragung der Nutzerdaten an andere Spaces geregelt, und wenn ja, wie? Welche vertraglichen Regeln müssen für eine Föderation mit FabAccess festgehalten werden?
Föderierte Spaces arbeiten ggf. sehr unterschiedlich, was Maschineneinweisungen und Co. angeht - wie kann sichergestellt werden, dass dazu übergreifende Standards geteilt werden?

Stand der Föderation

Das Feature Föderation ist aktuell (Stand Dezember 2024) noch nicht in FabAccess implementiert.

Wer nutzt heute schon FabAccess?

Potentielle Nutzer für FabAccess-Föderation findest du unter Mitmachen / Unterstützen / Join the Community

Grundkonzepte

Measurements (Messwerte)

Durch "Measurements" in FabAccess werden Daten von Ressourcen gesammelt, um deren Leistung und Nutzung zu erfassen. Das Ziel ist es, dass FabAccess diese Messwerte sammelt und an die Nutzer weitergibt.

Die Funktion Measurements ermöglicht es FabAccess, wichtige Daten über die Nutzung von Ressourcen zu erfassen und den Nutzern zur Verfügung zu stellen. Dies umfasst Informationen wie Betriebsstunden, Auslastung und andere Leistungsindikatoren, die es den Nutzern ermöglichen, die Effizienz und Produktivität ihrer Arbeitsprozesse zu optimieren.

Hinweis: Das Konzept zu Measurements exitiert zwar, jedoch gibt es noch keine Spezifikation!

Grundkonzepte

RBAC (Benutzerrollen und Berechtigungen)

FabAccess verwendet eine Role-Based Access Control (RBAC)-Struktur zur Verwaltung von Berechtigungen. Dabei werden Berechtigungen Maschinenrollen zugewiesen, und diese Rollen werden dann den Benutzern zugewiesen. Auf diese Weise lässt sich ein komplexes Berechtigungssystem einfach, ufassend und flexibel abbilden.

Das Berechtigungssystem ermöglicht es, die Zugriffe auf Maschinen nur für bestimmt Nutzer zu erlauben. Somit kann darüber die Einweisungen für gefährliche Maschinen abgebildet werden. Auch die Abbildungen von einfachen Maschinen, die keine Einweisung benötigen, ist möglich.

Berechtigungsübersicht

Die Resourcen haben folgende Berechtigungen, die zugewiesen werden und dem Nutzer folgendes ermöglichen:

disclose (offenlegen)
die Resource über die API zu entdecken, also in einer Liste zu erhalten. Mit dieser Berechtigung können Nutzer die Maschine in der Maschinenliste der App sehen. Ohne diese Berechtigung wird die Maschine in der Liste nicht angezeigt.

read (lesen)
statische Informationen aus der Resource erhalten. Diese Berechtigung ermöglicht es Nutzern, Informationen zur Maschine abzurufen. Dazu gehört das Auslesen des aktuellen Zustands der Maschine und das Lesen weiterer Informationen wie Wiki-Links. Es ist wichtig zu beachten, dass ein Nutzer ohne disclose, aber mit read, die Maschine dennoch auslesen kann. Diese Funktion kann z.B. durch QR-Codes auf der Maschine als Präsenzfunktion genutzt werden.

write (schreiben)
Die write-Berechtigung ermöglicht es einem Nutzer, die Maschine zu verwenden. Auch das Ändern von Zuständen der Maschine wird dadurch möglich.

manage (verwalten)
einen claim zu überschreiben. Mit dieser Berechtigung kann die Maschine verwaltet werden. Ein Nutzer mit dieser Berechtigung kann eine verwendete Maschine freigeben oder als defekt markieren.

Nicht implementierte Berechtigungen

Folgende Berechtigungen sind konzipiert, aber aktuell nicht implementiert:

notify (benachrichtigen)
Notify aufrufen, um statische Informationen zu erhalten

claim (Anspruch erheben)
Die Resource leihen und Traits auszuführen

transfer (transferieren)
Die Resource an einen anderen Nutzer weitergeben

lend (ausleihen)
Die Resource an andere verleihen, die nicht die Berechtigung haben die Resource zu verwenden

Grundkonzepte

Plugins

Die modulare Struktur von FabAccess benötigt Plugins, um das System an die Bedürfnisse des Spaces anzupassen. Plugins ermöglichen die Erweiterung der Grundfunktionen von FabAccess und die Integration zusätzlicher Features, ohne dass die Kompatibilität des Kernsystems beeinträchtigt wird.

Plugins können an folgenden Hauptstellen eingesetzt werden:

Grundkonzepte

Projekte

"Projects" in FabAccess sollen die Zusammenarbeit zwischen den Nutzern fördern und gleichzeitig die Abrechnung von Maschinenzeiten verbessern. Ein wichtiger Aspekt der Projektstruktur ist die Möglichkeit für Nutzer, Claims innerhalb desselben Projekts miteinander zu teilen, um gleichzeitig auf Ressourcen zugreifen zu können.

Durch die Zuweisung von Nutzern zu Projekten können Teams effizient zusammenarbeiten und ihre Ressourcen optimal nutzen. Das Teilen von Claims innerhalb eines Projekts ermöglicht es den Teammitgliedern, nahtlos auf benötigte Ressourcen zuzugreifen und gemeinsam an Projekten zu arbeiten. Darüber hinaus erleichtert diese Funktionalität die Abrechnung von Maschinenzeiten, da die Nutzung der Ressourcen innerhalb eines Projekts besser nachverfolgt und zugeordnet werden kann.

Hinweis: Das Konzept zu Projekten exitiert zwar, jedoch gibt es noch keine Spezifikation!

Grundkonzepte

Terminals

Terminals in FabAccess bieten einen eingeschränkten Zugang zum Server. Diese Terminals können nur auf die ihnen zugewiesenen Maschinen zugreifen und haben die Möglichkeit, Maschinen an andere Benutzer auszuleihen.

Aufgrund ihrer eingeschränkten Zugriffsrechte sind Terminals ideal für die Authentifizierung in FabFire. Durch die Verwendung von Terminals als Authentifizierungsmethode können Benutzer sicherstellen, dass nur autorisierte Personen auf die Ressourcen zugreifen und diese nutzen.

Die Verwendung von Terminals zur Authentifizierung bietet eine zusätzliche Sicherheitsebene und hilft, die Integrität des Systems zu wahren. Darüber hinaus ermöglicht es eine effiziente Verwaltung der Ressourcennutzung, indem der Zugriff nur autorisierten Benutzern gewährt wird.

Grundkonzepte

Externe Authentifikation

Das Authentifizieren in FabAccess basiert vollständig auf SASL und unterstützt daher verschiedene Mechanismen.

Die Rollen, die aus den Gruppen bei LDAP und OAuth abgeleitet werden, werden additiv zu denen betrachtet, die intern in FabAccess vergeben werden.

Authentifikation per OAuth

In Entwicklung seit 10/2024 - Ansprechpartner: Jonathan Krebs

Authentifikation per LDAP

In Entwicklung seit 10/2024 - Ansprechpartner: Jonathan Krebs

Es besteht keine native LDAP Integration. Es gibt jedoch Tools zum Importieren von LDAP-Benutzern in die bffh-Datenbank. Siehe LDAP Anbindung.

Authentifikation per FabFire

FabFire ist eine Entwicklung, die auf NXP Mifare DESFire basiert und die Anwendung von Karten nutzt, um Benutzer über das OTA (Over the Air)-Verfahren zu authentifizieren.

Grundkonzepte

Nutzerverwaltung

Die Nutzerverwaltung ermöglicht es, den Überblick über die Nutzer im Space nicht zu verlieren. FabAccess ist als SmartCard System gedacht, somit erhält jeder Nutzer eine NXP Mifare DESFire (FabCard) Karte, um sich an der Maschinen zu authentifizieren.

Um den administrativen Aufwand zu verringern, können sich Nutzer selbstständig anmelden und können dann nach der Prüfung der Daten durch den Betreiber freigeschaltet werden. Die Schließung eines Nutzungsvertrages wird dabei abgebildet.

Mit der FabCard können Nutzer sich sowohl an den Maschinen authentifizieren als auch an unserem Client Borepin.

Grundkonzepte

Traits

Traits bieten die Möglichkeit, den Zustand von Ressourcen zu ändern. Ressourcen können mehrere Traits besitzen und diese kombiniert nutzen. Mit Traits erhalten Nutzer Zugriff auf die Ressource, nachdem sie einen [Claim](https://docs.fab-access.org/books/fabaccess-setup/page/claims-notify-und-interest-das-konzept-vom-anspruch-erheben "Claims, Notify und Interest (das Konzept vom "Anspruch erheben")") erhalten haben. Dabei können Traits verwendet werden, um Ressourcen aus bestehenden Traits zusammenzusetzen oder spezifische Traits zu implementieren. Um eine optimale Anzeige der Traits für Nutzer in Clients zu ermöglichen, kann einer Ressource ein "Hint" hinzugefügt werden. Dieser ermöglicht es einem Client, eine verbesserte Ansicht der Ressource für Nutzer zu generieren. Traits werden anhand einer OID (Object Identifier) bereitgestellt. In FabAccess gibt es bereits vordefinierte Traits für grundlegende Funktionen, mit denen viele Zustände von Ressourcen abgebildet werden können.

Übersicht über die vorhandenen Traits

Checkable

Der komplexere Trait "Checkable" ermöglicht die Abbildung von Ressourcen, die nach der Benutzung überprüft werden müssen. Bei einer Überprüfung durch einen berechtigten Nutzer kann die Ressource entweder für alle wieder freigegeben oder zurückgewiesen werden. Falls die Ressource zurückgewiesen wurde, kann der ursprüngliche Nutzer die Ressource weiterhin verwenden oder erneut zur Überprüfung einreichen, nachdem die Fehler behoben wurden.

OID 1.3.6.1.4.1.61783.612.1.3

States

als Mermaid

stateDiagram
    [*] --> FREE
    FREE --> INUSE: use
    INUSE --> CHECK: giveback
    CHECK --> FREE: accept
    CHECK --> REJECTED: reject
    REJECTED --> INUSE: use
    REJECTED --> CHECK: giveback
    REJECTED --> FREE: accept

Claimable

Der Trait "Claimable" stellt einen Sonderfall dar, da er dazu dient, dass sich ein Nutzer über den Claim-Zustand einer Ressource informieren kann.

Nutzer können auf diesem Trait keine Aktionen ausführen, sondern lediglich den Zustand abfragen.

OID 1.3.6.1.4.1.61783.612.1.0

Doorable

Der Trait "Doorable" ermöglicht die Abbildung von Türen oder anderen Schließsystemen. Dabei besteht die Möglichkeit, kurzzeitige Öffnungen zu realisieren. Die genaue Zeitdauer, für die die Ressource geöffnet wird, wird dabei vom Server bestimmt.

OID 1.3.6.1.4.1.61783.612.1.2

States

als Mermaid

stateDiagram
    [*] --> CLOSED
    CLOSED --> OPEN: unlock
    OPEN --> CLOSED: lock
    CLOSED --> tempOPEN: unlocktemp
    tempOPEN --> OPEN: unlock
    tempOPEN --> CLOSED: lock
    tempOPEN --> CLOSED: AUTO

Locatable

Der Trait "Locatable" ermöglicht die Identifizierung von Ressourcen, wie beispielsweise Schließfächer oder 3D-Drucker in einer Druckerfarm. Dabei kann entweder eine kurzfristige Identifikation abgegeben werden oder die Identifizierung dauerhaft gesetzt werden.

OID 1.3.6.1.4.1.61783.612.1.5

Lockers

"Lockers" ist einer der komplexeren Traits, mit dem Schlösser von Ressourcen genauer abgebildet werden können. Der Nutzer kann die Ressource nicht in jedem Zustand zurückgeben; erst wenn alles korrekt zurückgegeben wurde, kann die Ressource auch wieder gesperrt werden.

Die Zustandsänderungen zwischen den vom Nutzer verwendbaren Übergängen können von einem Initiator herbeigeführt werden.

OID 1.3.6.1.4.1.61783.612.1.4

States

als Mermaid

stateDiagram
    [*] --> locked
    locked --> unlocked: unengage
    unlocked --> locked: engage
    unlocked --> open: AUTO
    open --> unengaged: AUTO
    unengaged --> locked: engage
    unengaged --> open: AUTO

Powerable

"Powerable" ist der grundlegendste Trait, den FabAccess unterstützt. Er dient dazu abzubilden, ob eine Ressource eingeschaltet bzw. mit Strom versorgt ist.

OID 1.3.6.1.4.1.61783.612.1.1

Hinweis: Die Mermaid-Diagramme sind mit https://mermaid.live gerendert und als PNG exportiert und hier importiert worden, da BookStack keinen integrierten Mermaid Renderer besitzt.

Grundkonzepte

URL und URN

Ressourcen in FabAccess werden durch einen Namen dargestellt. Um jedoch die Suche nach Ressourcen zu verbessern, können diese Referenzen als URN (Uniform Resource Name) oder URL (Uniform Resource Locator) geschrieben werden.

Die URN ist ein Identifikator ohne Bezug zum Space, während die URL auch den Space referenzieren kann, um einen Austausch von Ressourcen zu ermöglichen.

Genutzte Schemata in FabAccess

Folgende URN Schemata werden in FabAccess verwendet:

Space Name: urn:fabaccess:lab:{spacename}
Space Info: urn:fabaccess:lab:{spacename}\x00{instanceurl}
- dieser Wert wird aktuell nicht verwendet, muss jedoch ausgefüllt werden, damit die Konfiguration bffh.dhall valide ist!
Maschinen: urn:fabaccess:resource:{machine id}