Deine Plattform hat eine Web-UI, eine REST-API, Dashboards, einen MQTT-Broker, einen KI-Agenten, vielleicht mehr. Jede Komponente muss wissen, wer aufruft und was derjenige darf. Das sind mindestens fünf Services, die jeweils Authentifizierung und Autorisierung brauchen.
Jetzt stell dir das Deployment vor. Dein Kunde nutzt Microsoft EntraID. Der "Standard"-Ansatz: Jeden Service als separate Applikation in seinem Tenant registrieren. Fünf App-Registrierungen. Fünf Sets von Scopes, Rollen und Claims-Mappings. Jede einzelne muss von der IT-Abteilung des Kunden konfiguriert, geprüft und freigegeben werden.
Deren IT-Team hat einen Rückstand von sechs Wochen.
Das N-zu-N-Problem
Das Grundproblem ist einfach. Ohne einen Federation-Broker braucht jeder Service in deiner Plattform seine eigene Beziehung zum Identity Provider des Kunden. Diese Beziehung ist kein One-Click-Setup -- sie umfasst:
- App-Registrierung im IdP-Tenant des Kunden
- Scope-Definitionen für das, was die App anfordern darf
- Rollen-Mappings, um IdP-Gruppen in Anwendungsberechtigungen zu übersetzen
- Claims-Konfiguration, damit die richtigen Attribute in den Tokens landen
- Redirect-URIs, Token-Laufzeiten, Consent-Flows
Multipliziere das mit der Anzahl der Services in deiner Plattform. Dann multipliziere mit der Anzahl der Kunden, jeder mit eigenem IdP, eigenen Sicherheitsrichtlinien, eigener Verfügbarkeit des IT-Teams.
Das ist Integrationshölle. Nicht weil eine einzelne Registrierung schwierig ist, sondern weil das Gesamtvolumen einen Koordinationsengpass erzeugt, der direkt bei der IT-Abteilung des Kunden liegt -- dem Team, auf das du am wenigsten Einfluss hast.
Liefer den Auth-Server mit, nicht das Problem
Die Alternative: Einen eigenen Identity-Broker als Teil der Plattform ausliefern. Wir nutzen Keycloak, aber das Muster funktioniert mit jedem standardbasierten Identity-Server.
Die zentrale Erkenntnis ist, dass die gesamte Komplexität von "welcher Service braucht welche Scopes" und "welche Rolle wird auf welche Berechtigung gemappt" dein Domänenwissen ist, nicht das des Kunden. Du weisst, wie deine Plattform funktioniert. Du weisst, dass das Dashboard Lesezugriff braucht, dass die API Schreibzugriff braucht, dass der MQTT-Broker topic-basierte Autorisierung braucht. Warum diese Konfiguration jemand anderem aufbürden?
Mit einem mitgelieferten Auth-Server ist jeder interne Service bei der Installation vorkonfiguriert. Benutzer, Rollen, Berechtigungen, Client-Konfigurationen -- alles sofort einsatzbereit. Die IT-Abteilung des Kunden macht genau eines: eine einzelne OIDC- oder SAML-Federation-Verbindung von ihrem IdP zu deinem einrichten.
Eine Verbindung. Ein Nachmittag. Fertig.
Was dir das konkret bringt
Schneller zum ersten Login. Statt wochenlang auf die IT-Abteilung des Kunden zu warten, bist du am selben Tag betriebsbereit. Die Federation-Verbindung ist ein Standard-OIDC-Setup, das jeder Identity-Admin schon gemacht hat.
Kein Kunden-IT-Aufwand bei neuen Services. Neues Analytics-Modul ausgeliefert? KI-Assistenten hinzugefügt? Neuen Protokoll-Adapter angeschlossen? All das ist in deinem Auth-Server vorkonfiguriert. Der Kunde merkt nichts -- er loggt sich ein und sieht das neue Feature.
IdP-Unabhängigkeit. Deine Plattform funktioniert heute mit EntraID, morgen mit Google Workspace, nächstes Quartal mit Okta. Der Kunde wechselt den Identity Provider? Du aktualisierst eine Federation-Verbindung. Dein Plattform-Code ändert sich nicht.
Offline-Betrieb. Edge-Deployments sind per Definition nicht immer verbunden. Ein mitgelieferter Auth-Server authentifiziert Benutzer weiter, auch wenn die Cloud-Verbindung ausfällt. Tokens werden lokal ausgestellt, lokal zwischengespeichert, lokal validiert. Kein Internet nötig.
Autorisierung, die dein Business versteht
Authentifizierung (wer bist du?) ist nur die halbe Miete. Autorisierung (was darfst du?) ist der Bereich, in dem die meisten Plattformen entweder unterliefern oder komplett an den IdP delegieren.
EntraID, Okta und ähnliche Anbieter sind hervorragend im Verwalten von Identitäten. Sie sind nicht dafür gemacht, dein Berechtigungsmodell abzubilden. Namespace-bezogener Zugriff auf bestimmte Maschinen in einer Fertigungshalle? Rollenbasierte Dashboards, in denen Bediener Produktionsdaten sehen, aber keine Konfiguration? Service-übergreifende Durchsetzung, bei der dieselbe Berechtigung für API, MQTT-Broker und Dashboard gilt?
Das ist Geschäftslogik. Sie gehört in deine Plattform.
Ein mitgelieferter Auth-Server ermöglicht Autorisierungsregeln, die zu deiner Domäne passen:
- Rollenbasierter Zugriff -- Admin, Ingenieur, Bediener, Analyst -- jede Rolle mit einem klar vorkonfigurierten Berechtigungsset über alle Services hinweg.
- Namespace-bezogene Berechtigungen -- Zugriff auf bestimmte Teilbäume deiner Datenhierarchie. Ein Bediener in Werk A sieht die Daten von Werk B nicht.
- Service-übergreifende Durchsetzung -- dasselbe Berechtigungsmodell regelt REST-API, MQTT-Broker, Dashboards und KI-Agent. Eine Policy, überall angewandt.
- Vorkonfiguriert, nicht nachgerüstet -- wird mit der Plattform ausgeliefert. Keine Custom Claims in EntraID, keine Conditional-Access-Policies pro Service, keine extern zu pflegenden App-Rollen.
Gleichwertige Autorisierung in einem Kunden-EntraID aufzubauen, würde Custom-App-Rollen pro Service, Conditional-Access-Policies und tiefes Verständnis der Plattform-Interna erfordern. Das ist keine zumutbare Anforderung an das IT-Team des Kunden, und nichts, was du über Dutzende von Deployments supporten willst.
Der Vergleich auf einen Blick
| Aspekt | Direkte IdP-Integration | Mitgelieferter Auth-Server |
|---|---|---|
| App-Registrierungen im Kunden-IdP | 1 pro Service (5-10+) | 1 insgesamt |
| Aufwand Kunden-IT | Erheblich -- wochenlanger Rückstand | Minimal -- eine OIDC-Verbindung, am selben Tag |
| Neuen Plattform-Service hinzufügen | Neue App-Registrierung + IT-Ticket | Vorkonfiguriert, keine Kundenaktion nötig |
| Autorisierungsgranularität | Beschränkt auf IdP-Möglichkeiten | Geschäftslogik-nah, namespace-bezogen |
| Offline-Betrieb | Keine Authentifizierung möglich | Voll funktionsfähig mit gecachten Tokens |
| IdP-Vendor-Lock-in | Eng an einen Anbieter gekoppelt | Anbieterunabhängig durch Federation |
Deployment-Flexibilität
Ein unterschätzter Vorteil: Der Auth-Server passt sich an, wie und wo deine Plattform läuft.
- Einzelner Edge-Node -- Auth-Server läuft direkt auf dem Gerät. Vollständig autonom, funktioniert auch ohne Netzwerk.
- Zentraler Hub -- ein Auth-Server für eine Flotte von Edge-Nodes. Zentrale Benutzerverwaltung.
- Hybrid -- Federation zum IdP des Kunden wenn online, Fallback auf lokale Authentifizierung wenn offline.
Das ist relevant für industrielle Deployments, in denen Konnektivität nicht garantiert ist und verschiedene Kunden grundlegend unterschiedliche Infrastrukturanforderungen haben.
Der Trade-Off
Einen Identity-Broker mitzuliefern bedeutet, einen weiteren Service mitzuliefern. Keycloak braucht eine Datenbank, verbraucht Speicher, erfordert Updates. Auf einem ressourcenbeschränkten Edge-Gerät ist das nicht kostenlos. Du tauschst kundenseitige Integrationskomplexität gegen plattformseitige Betriebskomplexität -- Komplexität, die du kontrollierst und automatisieren kannst, aber dennoch Komplexität.
Für Plattformen mit drei oder mehr authentifizierten Services, die On-Premise deployed werden, rechnet sich der Trade-Off schnell. Die Koordinationskosten für N App-Registrierungen über M Kunden hinweg übersteigen die Kosten für einen weiteren Container bei weitem.
Erste Schritte
Falls du dieses Muster für deine eigene Plattform evaluierst:
- Zähle deine Services. Liste jede Komponente auf, die Authentifizierung braucht. Sind es mehr als drei, ist das N-zu-N-Problem bereits real.
- Modelliere dein Autorisierungsmodell. Schreib die Rollen und Berechtigungen auf, die deine Plattform braucht. Wenn sie über "Admin" und "User" hinausgehen, brauchst du wahrscheinlich geschäftslogik-nahe Autorisierung, die ein generischer IdP nicht liefern kann.
- Prüfe deine Deployment-Szenarien. Wenn du jemals On-Premise, am Edge oder in Umgebungen ohne garantiertes Internet deployst, ist lokale Auth-Fähigkeit nicht optional.
- Wähle einen standardbasierten Broker. Keycloak, Authentik oder ähnliche. Die Kernanforderungen: OIDC/SAML-Federation, feingranulare Autorisierung und die Fähigkeit, eigenständig zu laufen.
Die initiale Investition ist überschaubar. Der Gewinn -- gemessen an Deployment-Geschwindigkeit, Kundenzufriedenheit und Nächten, die du nicht mit dem Debuggen von EntraID-Claims-Mappings verbringst -- ist erheblich.
PREKIT wird mit einer vorkonfigurierten Keycloak-Instanz als Teil jedes Deployments ausgeliefert, die Authentifizierung und namespace-bezogene Autorisierung für alle Plattform-Services out of the box abdeckt. Bei Fragen zur Architektur oder um zu besprechen, wie dieses Muster auf deine Plattform passt, melde dich bei uns.