SSO und ein Audit-Log, ohne Enterprise-Vertriebsgespräch

Single Sign-On wird auf den meisten Plattformen als Enterprise-Feature behandelt, hinter einem Vertriebsgespräch und einem Preis versteckt, der ein paar hundert Lizenzen voraussetzt. Die meisten Teams, die es wirklich wollen, sind klein – eine Handvoll Engineers, die lieber kein separates Passwort für das eine Tool pflegen, das Produktion neu starten kann.

Die Einrichtung

Einstellungen → Single Sign-On, nur für Admins. Beide gängigen Fälle werden direkt unterstützt, nicht nur einer mit dem anderen nachträglich angeflanscht:

OpenID Connect – Google Workspace, Okta, Microsoft Entra, Authentik, Keycloak oder jeder andere OIDC-Anbieter:

1. Erstelle eine OpenID-Connect-Web-App bei deinem Identity Provider, mit der Redirect-URI, die die Seite dir zeigt.
2. Trage Issuer-URL, Client-ID, Client-Secret und die E-Mail-Domain ein, für die das gilt.
3. Wähle die Rolle, mit der neue Leute beitreten – Viewer, Deployer oder Admin.
4. Optional SSO für diese Domain erzwingen, wodurch der Passwort-Login für sie komplett deaktiviert wird.

SAML 2.0 – auf derselben Seite auswählen, Sign-in-URL und Zertifikat des Identity Providers einfügen, und Railyard zeigt die ACS-URL, Entity-ID und SP-Metadaten, die du an Okta, Entra, OneLogin, JumpCloud oder ADFS weitergibst. Antworten werden auf Signatur, Audience, Zeit und Request-ID geprüft – nicht einfach akzeptiert, weil sie sich parsen ließen.

Bevor sich irgendjemand tatsächlich über eine der beiden Methoden anmelden kann, muss die Domain mit einem TXT-Eintrag verifiziert werden (_railyard-sso.<domain>) – SSO meldet sich nie bei einem Site-Operator-Konto oder einem Konto außerhalb des Teams an, und Zwei-Faktor ist auch für Leute, die über SSO kommen, weiterhin Pflicht.

SCIM, sobald SSO gespeichert ist

Richte die SCIM-2.0-App deines Identity Providers auf https://app.railyard.run/scim/v2 mit einem generierten Bearer-Token, und Team-Mitgliedschaft wird kein manueller Schritt mehr: Jemanden im Identity Provider zuweisen fügt ihn zum Team hinzu, ihn deaktivieren entfernt ihn. Owner werden auf diesem Weg nie entfernt – diese eine Rolle bleibt eine bewusste, menschliche Handlung.

Das Audit-Log, und was es wirklich abdeckt

Activity in der Sidebar erfasst Deploys, Variablenänderungen, Mitgliederänderungen, Freigaben und Datenjobs – filterbar nach Mitglied, App, Art und Zeitraum, exportierbar als CSV. Variablenänderungen zeigen, wer welchen Namen wann geändert hat, nie den Wert selbst, damit das Log nützlich ist, ohne selbst zu einer zweiten Stelle zu werden, an der Secrets durchsickern.

Der Teil, der wissenswert ist: Aktionen, die ein Railyard-Operator an eurem eigenen Team vornimmt – Limits ändern, sperren, wieder freischalten – landen im selben Log, nicht in einem separaten, das nur wir sehen. Wenn mit eurem Team etwas gemacht wurde, seht ihr es genauso, wie ihr seht, was eure eigenen Mitglieder getan haben.

Der Score, der zeigt, ob das alles tatsächlich aktiv ist

Einstellungen → Sicherheit prüft zehn Dinge und bewertet das Team von 0–100: Zwei-Faktor bei jedem Mitglied, Admins, die sich seit 90 Tagen nicht angemeldet haben, Server mit ausstehenden Sicherheitsupdates, EOL-Betriebssysteme, offene Ports, Zertifikatsablauf, Backup-Verifizierung, ungeschützte Stagings und API-Tokens ohne Ablaufdatum. Jeder fehlgeschlagene Check verlinkt direkt zur Behebung, damit „wir haben einen Security-Score“ nicht einfach ungelesen unten auf einer Einstellungsseite liegen bleibt.

Vollständige Referenz: Teams, SSO und Zugriff.