Stellwerk

Governance

Wer darf was — und warum.

In Stellwerk entsteht Zugriff nicht durch Anmelden, sondern durch einen ausdrücklichen Akt der Verwaltung. Jeder dieser Akte ist nachlesbar.

Die kurze Antwort

Eine gültige SSO-Anmeldung kommt nur herein, wenn es ein Nutzerkonto gibt oder das Token eine freigegebene Gruppe trägt. Wer drin ist, hat damit noch keine Rechte — die entstehen aus vier benannten Quellen, und die Ansicht „Wer darf was" zeigt zu jedem Recht, woher es kommt. Jede Änderung an dieser Verwaltung hinterlässt genau einen Protokolleintrag.

Das Problem

Drei Fragen, die die meisten Anbindungen nicht beantworten.

„Er hat sich angemeldet — also darf er?"

Bei vielen SSO-Anbindungen genügt ein gültiges Token aus dem Unternehmens-Verzeichnis. Wer im Verzeichnis steht, ist drin.

„Warum darf er das eigentlich?"

Rechte kommen aus Gruppen, Rollen und Vererbung. Was jemand darf, lässt sich meist anzeigen — woher es kommt, selten.

„Wer hat den Nutzer gelöscht?"

Zugriffe werden protokolliert, die Verwaltung selbst oft nicht. Der Eintrag verschwindet, und niemand kann sagen, ob Fehlklick oder Fehler.

So löst Stellwerk das

Vier Schritte, die aufeinander aufbauen.

  1. Zugang ist gebunden

    Eine SSO-Anmeldung kommt nur herein, wenn es ein Nutzerkonto gibt oder das Token eine freigegebene Gruppe trägt. Das ist kein Schalter und keine Betriebsart, sondern das einzige Verhalten. Der Leitstand zeigt jederzeit, wer hereinkommt, und warnt, wenn kein Zugangsweg mehr besteht — der Zugang der Verwaltung selbst hängt nie daran.

  2. Rechte haben eine Herkunft

    Was jemand darf, ist die Vereinigung aus vier Quellen: Basis-Zugang, Team über die lokale Mitgliedschaft, Team über eine Rolle aus dem Identity-Provider, persönliches Bündel. Die Ansicht „Wer darf was" beantwortet deshalb nicht nur, ob jemand darf, sondern woher das Recht stammt — und damit, an welcher Stelle man dreht. Angelegt zu sein heißt für sich genommen: noch keine Rechte.

  3. Der Entzug räumt mit auf

    Wird eine Gruppen-Freigabe entzogen, werden die Nutzer, die allein aus ihr entstanden sind, entfernt und ihre Lizenzplätze frei. Der Bestätigungsdialog nennt die Betroffenen vorher namentlich. Ein vorübergehend fehlender Rollen-Eintrag — Urlaub, Störung beim Identity-Provider — löscht dagegen nie jemanden.

  4. Jeder Verwaltungsakt hinterlässt eine Spur

    Jede Änderung über die Oberfläche und die Verwaltungs-Schnittstelle schreibt genau einen Protokolleintrag — Tokens, Nutzer samt Löschung, Zugangsdaten, Teams, Integrationen, Aufbewahrungsregeln. Reines Nachschauen schreibt nichts. In der Ansicht sind die Urheber unterscheidbar: ein konkreter Token, ein Mensch an der Verwaltung, oder der Server selbst. Ein Zugangsdaten-Wert steht dabei nie in einem Eintrag, Personen stehen als Kennung statt mit Namen.

Die Anmeldung

M. BergerEntra · gültiges Token
Nutzerkonto vorhanden?nein
Freigegebene Gruppe?nein
abgewiesen
Zugang
Admin-Akt: Gruppe SW-Buchhaltung freigegeben

Wer darf was — M. Berger

DarfHerkunftStand

Kein Zugang

Ohne Nutzerkonto und ohne freigegebene Gruppe gibt es nichts zu zeigen.

Angelegt — und noch ohne Rechte

Der Zugang ist da. Dürfen tut M. Berger deshalb noch nichts.

catalogBasis-Scopekonfiguriert
lexware_office_list_vouchersTeam „Buchhaltung" · lokalkonfiguriert
memory_appendTeam „Buchhaltung" · IdP-Rolleletzter Login
persönliches Bündel: leerkonfiguriert

Vereinigung aus vier Quellen. Kein „Deny", das ein „Allow" übersticht. Diese Ansicht zeigt die Herkunft — gedreht wird an der Quelle.

Protokoll der Verwaltung

09:12:04sso · release_group{"group":"SW-Buchhaltung"}Admin
09:14:37sso · provision_user{"user_id":"u_8f3a"}System
09:15:02team · add_member{"team":"buchhaltung","user_id":"u_8f3a"}Admin
09:41:55lexware-office · lexware_office_list_vouchersToken
AKT 1/4Eine gültige Anmeldung ist noch kein Zugang.

Ehrlich eingeordnet

Was diese Ansicht kann — und was sie bewusst nicht ist.

Die Ansicht „Wer darf was" ist eine Auskunft, kein Hebel — sie verlinkt die Stelle, an der man ändert. Drei der vier Quellen leitet sie live aus der Konfiguration ab; der Anteil, der aus den Rollen des Identity-Providers stammt, trägt sichtbar den Stand der letzten Anmeldung. Die Protokollierung der Verwaltung deckt die Oberfläche und die Verwaltungs-Schnittstelle ab.

Häufige Fragen

Was Betreiber uns dazu fragen.

Reicht ein gültiges Firmen-Login, um an die Systeme zu kommen?

Nein. Ein gültiges Token wird abgewiesen, solange es kein Nutzerkonto gibt und keine freigegebene Gruppe im Token steht. Berechtigung entsteht nie durch das Anmelden, sondern durch einen ausdrücklichen Akt der Verwaltung.

Kann ich einer einzelnen Person etwas gezielt verbieten?

Nicht als Verbot. Rechte sind die Vereinigung der vier Quellen; es gibt kein Verbot, das eine Erlaubnis übersticht. Wer etwas entziehen will, entfernt es an der Quelle — und die Ansicht „Wer darf was" zeigt, welche das ist.

Was passiert, wenn jemand aus der freigegebenen Gruppe herausfällt?

Beim Entzug der Freigabe durch die Verwaltung werden die allein daraus entstandenen Nutzer entfernt und ihre Lizenzplätze frei; die Betroffenen stehen vorher im Bestätigungsdialog. Fehlt der Rollen-Eintrag dagegen nur vorübergehend, wird niemand gelöscht.

Sehe ich, wer eine Einstellung geändert hat?

Ja. Jede Änderung über die Oberfläche und die Verwaltungs-Schnittstelle erzeugt genau einen Protokolleintrag, und die Ansicht unterscheidet, ob ein Token, ein Mensch an der Verwaltung oder der Server selbst gehandelt hat.

Stehen Zugangsdaten oder Namen im Protokoll?

Nein. Ein Zugangsdaten-Wert steht in keinem Eintrag — bei einer Änderung nur Name und Namensraum. Personen erscheinen als Kennung, nicht mit Anzeigename oder E-Mail-Adresse.

Selbst ausprobieren

In 5 Minuten selbst testen.

Ein docker compose up, Port 8484 — das 30-Tage-Trial mit vollem Funktionsumfang ist im Produkt eingebaut. Kein Phone-Home.

Quickstart öffnen