Zum Hauptinhalt springen

Unternehmens-SSO (OIDC) & Multi-Faktor-Authentifizierung (MFA)

Ort der Konfiguration

Unternehmensadministratoren erreichen diese Einstellungen über Einstellungen → Unternehmen, in den Tabs Anmeldemethoden und Zwei-Faktor-Authentifizierung.

Unternehmens-VPN, -Proxy oder -Firewall

Wenn sich Ihre Benutzer hinter einem VPN, einem Unternehmens-Proxy oder einer Firewall mit SSL-Inspektion anmelden, können einige SSO-Flüsse blockiert oder verändert werden (Status-Cookie entfernt, Identitätsdomänen nicht erreichbar). Das typische Symptom ist eine Anmeldung, die fehlschlägt oder in einer Schleife läuft — während SSO ohne VPN funktioniert. Geben Sie Ihrem Netzwerkteam die Netzwerkfluss-Matrix, um die erforderlichen Domänen ohne SSL-Inspektion und ohne Cookie-Umschreibung freizugeben.

Verfügbare Anmeldemethoden

FoxPlan unterstützt mehrere Authentifizierungsansätze:

  • Passwort
  • Google Sign-in
  • Microsoft Sign-in
  • Unternehmens-SSO (OIDC)
Wichtig

Unternehmensadministratoren behalten immer die Anmeldung per Passwort, selbst wenn diese für das Unternehmen deaktiviert ist. So wird vermieden, dass man aus FoxPlan ausgesperrt wird, falls der Identitätsanbieter nicht verfügbar ist.

Ausnahmen: das Passwort für bestimmte Benutzer beibehalten

Wenn Sie Ihre Organisation auf SSO umstellen, können Sie die Passwort-Anmeldung für alle außer einer Liste ausgewählter Benutzer deaktivieren.

Deaktivieren Sie das Kontrollkästchen Passwort: Unter den Kontrollkästchen erscheint dann ein Auswahlfeld „Ausnahmen: Benutzer, die das Passwort behalten". Wählen Sie dort die betroffenen Benutzer aus und speichern Sie.

Tab Anmeldemethoden mit der Ausnahmeliste

Diese Benutzer sehen weiterhin das Passwortfeld auf dem Anmeldebildschirm, während alle anderen über SSO oder die Google-/Microsoft-Anmeldung gehen müssen.

Typische Anwendungsfälle:

  • Notfallkonten („Break-glass") für den Fall eines Ausfalls des Identitätsanbieters
  • Dienstleister oder Externe, die nicht in Ihrem Unternehmensverzeichnis enthalten sind
  • Schrittweise Migration: die Teams in Wellen auf SSO umstellen
Tipp

Das Auswahlfeld ist nur sichtbar, wenn die Methode Passwort deaktiviert ist: Solange sie aktiv ist, gilt sie bereits für alle, und keine Ausnahme ist erforderlich.

MFA-Optionen

Organisationen können wählen zwischen:

  • TOTP (kompatibel mit Google Authenticator, Microsoft Authenticator, Okta, Keycloak)
  • Verifizierung per E-Mail
  • Kein MFA

Geltungsbereich: für wen die Zwei-Faktor-Authentifizierung gilt

Sobald eine Methode ausgewählt ist (TOTP oder E-Mail), erlaubt ein Abschnitt „Gilt für" die Auswahl der betroffenen Benutzergruppe:

OptionWirkung
Alle BenutzerDie Zwei-Faktor-Authentifizierung gilt für das gesamte Unternehmen (Standardverhalten).
Nur die aufgeführten BenutzerNur die ausgewählten Benutzer durchlaufen die Zwei-Faktor-Authentifizierung.
Alle Benutzer außer den aufgeführtenDie Zwei-Faktor-Authentifizierung gilt überall, außer für die ausgewählten Benutzer.

Für die beiden letztgenannten Modi steht ein Auswahlfeld zur Verfügung, um die betroffenen Benutzer zu bestimmen.

Tab Zwei-Faktor-Authentifizierung mit dem Geltungsbereich

Typische Anwendungsfälle:

  • Schrittweise Einführung: mit „Nur die aufgeführten Benutzer" und einem Pilotteam beginnen, dann auf „Alle Benutzer" umstellen.
  • Gezielte Verstärkung: die Zwei-Faktor-Authentifizierung nur für Administratoren und sensible Profile verlangen.
  • Technische Ausnahmen: Konten, die keine MFA-Abfrage beantworten können (Servicekonten, gemeinsam genutzte Terminals), über „Alle Benutzer außer den aufgeführten" ausnehmen.

Der Geltungsbereich wird serverseitig durchgesetzt: Ein Benutzer außerhalb des Geltungsbereichs meldet sich direkt an, ohne MFA-Abfrage, selbst wenn eine Methode für das Unternehmen aktiv ist.

Vorsicht

Im Modus „Alle Benutzer außer den aufgeführten" stellt jeder ausgenommene Benutzer eine Schwächung des Sicherheitsniveaus dar. Überprüfen Sie diese Liste regelmäßig.

Anmeldeablauf

  1. Der Benutzer gibt seine E-Mail-Adresse ein und fährt fort
  2. FoxPlan ermittelt das zugehörige Unternehmen
  3. Die für diese Organisation verfügbaren Authentifizierungsmethoden werden angezeigt
  4. Der Benutzer wählt je nach aktivierten Optionen Passwort oder SSO

Bei Passwortabläufen greifen die MFA-Abfragen. SSO-Abläufe delegieren die Authentifizierung an den Identitätsanbieter.

Konfiguration des Unternehmens-SSO (OIDC)

FoxPlan unterstützt OIDC-Anbieter: Okta, Keycloak, Google, Microsoft sowie individuelle Implementierungen.

Auf Seiten des Identitätsanbieters:

  • Eine OIDC-Anwendung vom Typ Web anlegen
  • Weiterleitungs-URL: {origin}/login/oauth2/code/{registrationId}
  • Client ID, Client Secret (oder Zertifikat, siehe unten) und Issuer URI erfassen

Im SSO-Formular von FoxPlan:

  • Auswahl des Anbieters
  • Anzeigename
  • Client ID
  • Client-Authentifizierung: geteiltes Secret oder Zertifikat
  • Issuer URI
  • Scopes: openid,profile,email
  • Username-Attribut (typischerweise sub oder email)
  • Aktivierungsschalter

Client-Authentifizierung: Secret oder Zertifikat

Der Tausch des Autorisierungscodes gegen ein Token ist der einzige Aufruf, den FoxPlan direkt an den Identitätsanbieter richtet, von Server zu Server. FoxPlan muss sich dabei ausweisen, und das Feld Client-Authentifizierung bietet dafür zwei Wege.

Client Secret (Standard). Ein geteiltes Geheimnis, auf beiden Seiten hinterlegt. Das ist der bisherige Modus, und für bestehende Konfigurationen ändert sich nichts: ohne ausdrückliche Auswahl bleiben sie dabei.

Zertifikat (privater Schlüssel). FoxPlan signiert eine JWT-Assertion mit einem privaten Schlüssel, und der Anbieter prüft sie mit dem öffentlichen Zertifikat, das Sie dort hinterlegt haben (private_key_jwt, RFC 7523). Das Geheimnis wird dann nie über das Netz übertragen — deshalb untersagen viele IT-Abteilungen inzwischen Client Secrets.

Es erscheinen dann zwei Felder:

  • Client-Zertifikat: das X.509-Zertifikat im PEM-Format. Es ist die öffentliche Hälfte und muss ebenfalls beim Identitätsanbieter hinterlegt werden (in Entra ID: Certificates & secretsCertificates).
  • Privater Schlüssel: im unverschlüsselten PKCS#8-Format, das mit -----BEGIN PRIVATE KEY----- beginnt. Ein PKCS#1-Schlüssel (BEGIN RSA PRIVATE KEY) oder ein passwortgeschützter Schlüssel wird abgelehnt, samt dem Befehl zur Umwandlung.

So erzeugen Sie ein Schlüsselpaar:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out zertifikat.pem -days 730 -nodes -subj "/CN=foxplan-sso"
openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-pkcs8.pem

Hinterlegen Sie zertifikat.pem beim Anbieter und fügen Sie key-pkcs8.pem in FoxPlan ein.

Der private Schlüssel wird verschlüsselt gespeichert, nie von der API zurückgegeben und nie erneut angezeigt: Lassen Sie das Feld beim Bearbeiten leer, bleibt der gespeicherte Schlüssel erhalten. Das Zertifikat dagegen ist öffentlich und bleibt sichtbar.

Ein Zertifikat läuft ab

Anders als ein Secret trägt ein Zertifikat ein Enddatum. Ist es überschritten, steht das SSO sofort still.

Die Frist wird deshalb dauerhaft angezeigt: Die Liste der Konfigurationen enthält eine Spalte Authentifizierung, die für jedes SSO zeigt, ob es sich mit Secret oder Zertifikat authentifiziert — und im zweiten Fall das Ablaufdatum, im letzten Monat davor orange, danach rot. Dieses Datum wird nie eingetippt: Es wird bei jeder Anzeige aus dem Zertifikat selbst gelesen, der einzigen Quelle, die nicht von der Wirklichkeit abweichen kann. Konfiguration prüfen liefert alle Einzelheiten, einschließlich Fingerabdruck.

Konfiguration je Anbieter

Google — Issuer URI: https://accounts.google.com

Microsoft / Azure — Issuer: https://login.microsoftonline.com/{tenantId}/v2.0

Okta — Web-App-Typ mit passender Zuweisung und passenden Zugriffsrichtlinien

Keycloak — Issuer URI des Realms, konfigurierter Authorization-Code-Flow

Vor dem Ablauf gewarnt werden

Eine Anzeige setzt voraus, dass jemand hinsieht. FoxPlan warnt deshalb von sich aus: Eine E-Mail geht an die Administration des Unternehmens, zu drei Zeitpunkten — dreißig Tage, sieben Tage und an dem Tag, an dem das Zertifikat abgelaufen ist. Die Nachricht nennt den betroffenen Anbieter, gibt das Datum an und verweist auf den Konfigurationsbildschirm.

Jede Stufe wird nur einmal gemeldet: Der Durchlauf merkt sich, was bereits verschickt wurde. Sobald das Zertifikat erneuert ist — die Frist also wieder über dreißig Tagen liegt — stellt sich der Zähler von selbst auf das nächste Zertifikat um. Es ist nichts zu tun.

Ist keine Unternehmensadministration hinterlegt, geht keine E-Mail hinaus: ein Grund mehr, diese Liste in den Mitgliedern des Unternehmens aktuell zu halten.

Wenn die Anmeldung fehlschlägt

Wer sich per SSO nicht anmelden kann, landet wieder auf dem Anmeldebildschirm — mit einem Satz, der die Ursache benennt, statt mit einem Code des Identitätsanbieters:

Was die Person siehtWas zu tun ist
Das Anmeldezertifikat ist abgelaufenZertifikat erneuern und auf beiden Seiten neu hinterlegen
Das Zertifikat ist unbrauchbarPrüfen, ob der private Schlüssel zum Zertifikat passt
Der Anbieter hat die Anmeldedaten von FoxPlan abgelehntDas Secret wurde beim Anbieter geändert, oder das Zertifikat ist dort nicht hinterlegt
Keine aktive SSO-VerbindungDie Konfiguration ist deaktiviert oder fehlt
Der Anbieter hat den Zugriff verweigertDas Konto ist beim Anbieter nicht für die Anwendung freigegeben

Die technischen Einzelheiten — die genaue Meldung des Anbieters, der vollständige Stacktrace — bleiben in den Serverprotokollen, für den Support. Die Person erhält einen Satz, der ihr sagt, an wen sie sich wenden kann.

Die Konfiguration vor dem Test prüfen

Jede Konfiguration in der Liste trägt eine Schaltfläche Konfiguration prüfen. Sie öffnet einen Bericht, der den Bildschirm nicht verlässt und keine Anmeldung versucht:

  • die URLs, die beim Identitätsanbieter zu hinterlegen sind, jeweils mit Kopierschaltfläche: die Weiterleitungs-URL und die URL zum Start der Anmeldung. Es sind genau jene, die die Anwendung verwenden wird — sie müssen nicht von Hand zusammengesetzt werden;
  • die Konsistenzprüfungen: Pflichtfelder ausgefüllt, Discovery-Dokument vom Server gelesen, Aussteller und Endpunkte in Übereinstimmung mit dem, was der Anbieter veröffentlicht. Bei Authentifizierung per Zertifikat prüft der Bericht zusätzlich, ob der private Schlüssel zum Zertifikat passt, zeigt den SHA-1-Fingerabdruck — denselben wie die Konsole des Anbieters — und weist auf ein abgelaufenes oder bald ablaufendes Zertifikat hin.

Drei Stufen: grün, wenn alles stimmt, orange für einen Punkt, den man ansehen sollte, rot für das, was die Anmeldung verhindern wird. Die Angabe rechts neben jeder Zeile ist der Rohwert — URL, HTTP-Status, Meldung des Anbieters — genau das, was man an den Support weitergibt.

Eine Prüfung kann als „URL nicht abgefragt" gemeldet werden: Der Server ruft nur öffentliche https-Adressen auf, die Konfiguration ist nicht die Ursache.

Dieser Bericht ist schreibgeschützt: Er ändert die Konfiguration nie.

Fehlerbehebung

Prüfen Sie bei Authentifizierungsproblemen folgende Punkte:

  • Die Weiterleitungs-URL stimmt zwischen IdP und FoxPlan exakt überein
  • Die SSO-Konfiguration ist tatsächlich aktiviert
  • Die E-Mail-Adresse des Benutzers gehört zum richtigen Unternehmen
  • Prüfen Sie bei Okta/Azure/Keycloak die Zuweisung und die Einhaltung der Policies
  • Prüfen Sie bei Benutzern mit Passwort+MFA die Registrierung (TOTP-Secret oder gültige E-Mail)