Single Sign-On (SSO)

Orimora unterstützt Single Sign-On pro Team — jeder Workspace kann seinen eigenen Identity Provider (IdP) mitbringen. Zwei Protokolle stehen zur Verfügung:

• OIDC (OpenID Connect) — Okta, Microsoft Entra ID, Google, Auth0, Keycloak …
• SAML 2.0 — dieselben IdPs plus JumpCloud, OneLogin und weitere Enterprise-IdPs.

Die prozessweiten Env-Provider (OIDC_* sowie Google/Microsoft) funktionieren weiterhin als instanzweiter Fallback.

Wie sich Nutzer anmelden

Auf der Login-Seite gibt der Nutzer seine E-Mail ein und klickt Mit Firmen-SSO anmelden. Orimora ordnet die Domain der E-Mail dem konfigurierten Provider des Teams zu und leitet in den passenden Ablauf weiter. Ein Team ist auch direkt über seinen Slug erreichbar:

• OIDC: /auth/oidc?team=<team-slug>
• SAML: /auth/saml/login?team=<team-slug>

Ein Provider wird nur per E-Mail automatisch erkannt, wenn seine erlaubten Domains gesetzt sind (sonst würde er jede Adresse matchen); ein solcher Provider ist nur über den Team-Slug erreichbar. Neue Nutzer werden beim ersten Login angelegt (JIT) und dem SSO-Team zugeordnet; bestehende Mitglieder werden nie neu zugewiesen.

Achtung

Setze APP_URL auf deinen öffentlichen https://…-Origin, bevor du SSO aktivierst — er ist die Basis für Redirect-URIs, die OIDC-Issuer-Prüfung und die SAML-EntityID/ACS-URL.

SSO und team-erzwungenes MFA

Aktivierst du team-erzwungenes MFA, erfüllt ein SSO-Login die Anforderung nur, wenn die Assertion des IdP belegt, dass MFA durchgeführt wurde — ein OIDC-amr von mfa (oder ein anerkannter zweiter Faktor) oder ein MFA-SAML-AuthnContextClassRef (z. B. Microsoft Entras http://schemas.microsoft.com/claims/multipleauthn). Ein Single-Factor-SSO-Login wird als noch-nicht-MFA erfasst, und das Mitglied muss trotzdem einen lokalen Faktor einrichten. Damit SSO erzwungenes MFA erfüllt, konfiguriere deinen IdP so, dass er MFA verlangt und assertet.

Provider konfigurieren

Öffne Einstellungen → Identität (SSO) (erfordert die Capability settings.team_edit).

OIDC

1. OIDC-Provider hinzufügen und ausfüllen: Anzeigename, Issuer-URL, Client-ID, Client-Secret, optionaler Scope (Standard openid email profile).
2. Optional erlaubte E-Mail-Domains setzen, um die E-Mail-basierte Erkennung zu aktivieren und die Anmeldung auf diese Domains zu beschränken.
3. Die Redirect-URI \${APP_URL}/auth/oidc/callback im IdP registrieren.
4. Den Provider aktivieren.

SAML 2.0

Zuerst das instanzweite SP-Signaturschlüsselpaar konfigurieren (ein Paar für alle Teams):

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout sp-key.pem -out sp-cert.pem -days 1095 -subj "/CN=orimora-sp"
# SAML_SP_PRIVATE_KEY und SAML_SP_CERT aus diesen PEM-Dateien setzen

Dann unter Einstellungen → Identität (SSO) → SAML-Provider hinzufügen die IdP-Entity-ID (Issuer), die IdP-SSO-URL, das Signaturzertifikat des IdP (PEM), das NameID-Format, optional das Email-Attribut und optionale erlaubte Domains eintragen.

Gib deinem IdP diese SP-Daten:

• SP-Metadata: \${APP_URL}/auth/saml/metadata
• ACS (HTTP-POST): \${APP_URL}/auth/saml/acs
• Entity ID: \${APP_URL}/auth/saml/metadata

Sicherheitsmodell

Jede SAML-Assertion wird gegen das hinterlegte Signaturzertifikat des Providers geprüft. Orimora erzwingt: eine gültige XML-Signatur (inkl. Abwehr von XML-Signature-Wrapping), den erwarteten Issuer und die Audience, die NotBefore/NotOnOrAfter-Gültigkeit (± Clock-Skew), eine Single-Use-InResponseTo- Korrelation (Replay-Schutz) und einen Success-Status — danach greift die Domain-Richtlinie.

Hinweis

Das MVP unterstützt SP-initiiertes SSO. IdP-initiierter Login und Single Logout (SLO) sind noch nicht implementiert (/auth/saml/slo liefert 501); die Abmeldung beendet nur die lokale Session. Vor dem Produktiveinsatz von SAML wird ein Security-Review/Pentest empfohlen.

Automatische Bereitstellung (SCIM 2.0)

SCIM lässt deinen IdP Nutzer automatisch anlegen, aktualisieren und deaktivieren — und Gruppen synchronisieren —, sodass du Konten nicht von Hand verwalten musst.

Einrichtung

1. Unter Einstellungen → Identität (SSO) im Bereich SCIM-Bereitstellung auf SCIM-Token erstellen klicken. Token sofort kopieren — er wird nur einmal angezeigt.
2. In den Provisioning-Einstellungen deines IdP setzen:
   • Tenant- / Basis-URL: \${APP_URL}/scim/v2
   • Secret-Token: der eben erstellte Token
3. Mindestens userName → E-Mail mappen. Provisioning starten.

Verhalten

• Users (/Users): anlegen, lesen, ersetzen (PUT), aktualisieren (PATCH) und löschen. Die Bereitstellung ist idempotent — dieselbe Nutzeranlage (gematcht über externalId, dann E-Mail) aktualisiert statt zu duplizieren.
• Deaktivierung ist nicht-destruktiv. active=false (oder ein SCIM-DELETE) sperrt den Nutzer — die E-Mail bleibt erhalten, sodass Reaktivierung funktioniert. Orimora löscht via SCIM nie hart.
• Neue Nutzer landen standardmäßig in der Gruppe Viewers (Least Privilege); weitergehender Zugriff folgt aus der Gruppenmitgliedschaft.
• Groups (/Groups): custom-Gruppen anlegen, Mitglieder patchen (add/remove/replace) und löschen. Die vier System-Gruppen (Admins/Editors/Members/Viewers) sind über SCIM read-only, und ein IdP kann den letzten Admin des Teams nicht entfernen.
• Filter unterstützen eq, co und sw bei Users (eq/co bei Groups); Pagination via startIndex/count; optimistische Nebenläufigkeit über ETag / If-Match.

Achtung

Ein SCIM-Token gewährt volle Nutzer-/Gruppen-Bereitstellung für sein Team — behandle ihn wie ein Passwort und widerrufe ihn, sobald er nicht mehr gebraucht wird. Tokens werden gehasht gespeichert und sind jederzeit über denselben Bildschirm widerrufbar. Vor dem Produktiveinsatz wird ein Pentest der SCIM-Oberfläche empfohlen.