SSO, Multi-Faktor-Authentifizierung und Rollenverwaltung gelten als Konzern-Themen mit Konzern-Preisschild. Sind sie aber nicht: Mit dem Open-Source-Identity-Provider Authentik läuft das Ganze selbst gehostet im eigenen Netz — und die wichtigste Architektur-Entscheidung dabei ist, wo Authentik gerade NICHT hingehört.
Das Problem: Jedes System bringt seine eigene Benutzerverwaltung mit
Wer mehrere Dienste betreibt — ein MDE-Terminal, ein Datenportal, ein Ticketsystem, ein Wiki — kennt den Wildwuchs: Jede Anwendung hat ihre eigenen Nutzer, ihre eigenen Passwörter, ihre eigene Vorstellung von Rollen. Das Ergebnis sind vergessene Alt-Accounts, Passwort-Zettel und die unangenehme Frage im Audit: Wer hat hier eigentlich noch worauf Zugriff?
Genau dafür gibt es Identity Provider. Die kommerziellen Varianten rechnen gerne pro Nutzer und Monat ab. Authentik macht dasselbe als Open Source, selbst gehostet — bei mir im Docker-Container auf Proxmox, hinter dem eigenen Reverse Proxy.
Was Authentik im Aufbau übernimmt
Ein Login für alles. Authentik spricht die beiden Mechanismen, die man in der Praxis braucht: Forward Auth für Anwendungen, die selbst keine Authentifizierung mitbringen (der nginx vor meinem MDE-Terminal fragt per auth_request bei Authentik nach, bevor er die Seite ausliefert), und OIDC für Anwendungen, die einen Standard-Login-Flow können — etwa ein Frappe-basiertes Datenportal. Einmal anmelden, überall drin.
MFA inklusive. TOTP und WebAuthn sind an Bord, ohne Zusatzmodul und ohne Aufpreis. Für alles, was von außen erreichbar ist, sollte das heute Standard sein.
Gruppen als Rollenmodell. Hier wird es für Maschinenhersteller interessant: Die Rollen aus dem Data Act — Betreiber, Drittpartei, Hersteller — lassen sich direkt als Authentik-Gruppen abbilden. Der Betreiber sieht alle Daten seiner Maschinen, der freigegebene Instandhalter nur seinen Ausschnitt, der Hersteller nur, was vertraglich vereinbart ist. Artikel 5 Data Act, klickbar statt als Paragraf.
Event-Log. Authentik protokolliert Anmeldungen und Verwaltungsvorgänge: wer, wann, wo. Zusammen mit der Wartungs-Protokollierung am Jump-Host (Stichwort Maschinenverordnung) erzählen zwei unabhängige Quellen dieselbe Geschichte — genau das, was man im Nachweisfall braucht.
Der unterschätzte Punkt: vorhandene Firmen-Logins andocken
Die Funktion mit dem größten Praxisnutzen ist unscheinbar: Authentik kann externe Identitätsquellen anbinden — Microsoft Entra ID, Google Workspace, klassisches LDAP.
Was das konkret bedeutet: Die Mitarbeiter eines Maschinenbetreibers melden sich am Datenportal mit dem Microsoft-Konto an, das sie ohnehin für Teams und Outlook nutzen. Es gibt kein neues Passwort, keine neue Nutzerverwaltung, keinen Pflegeaufwand. Und der oft übersehene Effekt: Verlässt ein Mitarbeiter die Firma, deaktiviert dessen IT das Microsoft-Konto — das tut sie sowieso. Damit ist auch der Portalzugriff weg, ohne dass irgendwer daran denken muss. Das Offboarding reitet auf einem Prozess mit, den der Betreiber schon hat.
Der Einrichtungsaufwand auf Betreiberseite ist überschaubar: eine App-Registrierung im Azure-Portal, etwa eine Viertelstunde für einen Admin. Drei Werte (Tenant-ID, Client-ID, Client-Secret) wandern in die Authentik-Konfiguration — fertig. In Projekten gehört dieser Schritt als Mitwirkungspflicht des Auftraggebers in die Vereinbarung, dann gibt es später keine Diskussionen.
Wo Authentik NICHT hingehört
Jetzt zur Architektur-Entscheidung aus der Einleitung: Authentik hängt bei mir bewusst nicht am MQTT-Broker.
Edge-Gateway und Jump-Host authentifizieren sich weiterhin per Client-Zertifikat direkt am Mosquitto, mit Topic-Rechten über die Broker-ACL. Technisch ließe sich auch der Broker an einen Identity Provider koppeln — aber Maschinen brauchen keinen Login-Flow, kein MFA und keinen Browser. Sie brauchen eine stabile, wartungsarme Verbindung, die auch dann funktioniert, wenn der Identity Provider gerade ein Update zieht oder neu startet.
Die Regel, auf die sich das eindampfen lässt:
Identität für Menschen. Zertifikate für Maschinen.
Wer beides über ein System zwingt, baut sich einen Single Point of Failure mitten in die Produktionsdatenerfassung. Die Trennung ist kein Kompromiss, sondern das sauberere Design: Authentik sichert die Mensch-Schnittstellen (Terminal, Portal, Verwaltung), mTLS sichert die Maschine-zu-Maschine-Pfade. Beide Welten treffen sich erst dort, wo Daten für Menschen sichtbar werden — und dort steuert die Gruppe die Sichtbarkeit, nicht der Broker.
Was sich damit bauen lässt
Zugriffsschutz für den Leitstand: Das MDE-Terminal ist nur noch für angemeldete Nutzer erreichbar, die Sichtbarkeit einzelner Bereiche hängt an der Gruppe.
Data-Act-Portal mit echter Rechtevergabe: Der Betreiber gibt Datenzugriff für einen Instandhalter oder Versicherer frei, indem er dessen Nutzer einer Gruppe zuordnet — statt eines Papierprozesses mit E-Mail-Anhängen.
Wartungszugriffe mit echter Identität: Der Service-Techniker authentifiziert sich, bevor der Jump-Host in die Maschinenzone freigeschaltet wird. Das Audit-Log kennt dann den Namen, nicht nur eine IP-Adresse — ein Baustein für die Eingriffs-Protokollierung nach Maschinenverordnung (EU) 2023/1230.
Fazit
Authentik ist eines dieser Open-Source-Werkzeuge, die eine vermeintliche Enterprise-Disziplin auf Mittelstandsformat bringen: Identitäts-Infrastruktur, die man selbst versteht, selbst betreibt und die vorhandene Firmen-Logins nutzt, statt neue Passwörter zu erzeugen. In Kombination mit einer klaren Trennung — Authentik an den Mensch-Schnittstellen, Client-Zertifikate an den Maschinen-Schnittstellen — entsteht eine Zugriffsarchitektur, die sowohl dem Data Act als auch der IEC 62443 standhält.
Sie planen ein Datenportal oder wollen Ihren Leitstand absichern, ohne eine neue Benutzerverwaltung zu erfinden? Sprechen Sie mich an.
Links: ▪ Authentik: https://goauthentik.io ▪ Live-Demo (IEC-62443-Aufbau mit MDE-Terminal): https://ctbifwpg.dms-iot.de ▪ Hintergrund Data Act: https://website.industrie-4-0.org/data-act-ab-september-2026-deine-maschine-muss-ihre-daten-rausruecken/