Anmeldung und SSO

Eine Instanz läuft entweder mit SSO oder mit Benutzerverwaltung in der Anwendung. Nicht beides, und es gibt keinen Rückfallweg von einem in den anderen.

Diese Entscheidung fällt vor dem Betrieb. Sie nachträglich zu drehen ist kein Schalter.

Der Normalfall: SSO

e-Request spricht OIDC gegen Keycloak. Wer kein eigenes Identity-Management betreibt, bekommt eine verwaltete Keycloak-Instanz dazu.

Wichtig: Bei aktivem SSO besitzt Keycloak die Rolle. Die Anwendung zeigt sie an, sie verwaltet sie nicht. Wer Rollen ändern will, tut das dann im Identity Provider — und wer das nicht weiss, sucht die Einstellung in der falschen Oberfläche.

Wenn Sie Entra ID oder AD FS einsetzen

Diese sprechen SAML. e-Request selbst implementiert kein SAML. Ihr SAML-Identity-Provider wird über Keycloak als föderierter Provider angebunden — das Brokering übernimmt Keycloak, nicht die Anwendung.

Das funktioniert und ist der vorgesehene Weg. Es ist aber eine Leistung, kein Häkchen: Die Anbindung gehört in die Planung und in das Angebot. Rechnen Sie nicht damit, dass sie „schon dabei” ist.

Der andere Modus: Benutzerverwaltung in der Anwendung

Eine Instanz kann auch ganz ohne Identity Provider laufen: Einladung per Mail, Passwort, Sperre gegen automatisiertes Durchprobieren. Rollen liegen dann in der Anwendung.

Die Lieferantenseite ist davon nicht betroffen

Lieferanten melden sich immer mit Benutzername und Passwort an — unabhängig davon, welchen Modus Ihre Einkaufsseite fährt. Es gibt kein SSO auf der Lieferantenseite, und das ist keine Lücke, sondern eine Entscheidung: Ein Lieferant arbeitet für viele Auftraggeber, und ein eigenes Konto pro Portal ist der Weg, der überall funktioniert.

Versprechen Sie einem Lieferanten also nie eine Anmeldung über sein Firmenkonto.

Zugänge beenden

Zugänge werden deaktiviert, nicht gelöscht — auf beiden Seiten. Wer einmal gehandelt hat, bleibt im Protokoll nachvollziehbar; aus dem Betrieb ist die Person sofort draussen. Siehe Benutzer und Zugänge.