SSO-Einrichtung
SSO-Einrichtung
Diese Anleitung richtet sich an IT-Administratoren, die einen unternehmenseigenen Identity Provider (IdP) mit InterMIND verbinden. Nach der Einrichtung melden sich Mitglieder über die normale Login-Seite an: Mit SSO anmelden → geschäftliche E-Mail → Ihr IdP → zurück in InterMIND.
Verfügbar in: Business- und Enterprise-Plan Konfiguriert von: Team-Owner oder Admin Protokoll: OpenID Connect (OIDC). SAML-2.0-Anmeldung ist in Entwicklung — SAML-Konfigurationen werden gespeichert, können aber noch nicht zur Anmeldung verwendet werden.
Voraussetzungen
- Eine verifizierte Domain — verifizieren Sie Ihre E-Mail-Domain zunächst per DNS-TXT-Eintrag (siehe Domain-Verwaltung). Die SSO-Anmeldung akzeptiert nur Konten, deren E-Mail-Domain von Ihrem Team verifiziert wurde; dies ist die Mandantengrenze.
- Ein IdP mit Unterstützung für OIDC mit Discovery — er muss
/.well-known/openid-configurationunter der Issuer-URL bereitstellen. Okta, Microsoft Entra ID und Google erfüllen dies.
Was Sie in Ihrem IdP registrieren
Erstellen Sie eine OIDC Web Application in Ihrem IdP mit:
| Einstellung | Wert |
|---|---|
| Redirect URI (Callback) | https://intermind.com/api/auth/sso/callback — wird auch in der SSO-Karte angezeigt, nachdem Sie OIDC ausgewählt haben |
| Grant Type | Authorization Code (PKCE S256 wird automatisch verwendet) |
| Scopes | openid email profile |
Das von Ihrem IdP ausgestellte ID-Token muss die email des Benutzers enthalten, und die Domain dieser E-Mail muss eine Ihrer verifizierten Domains sein — andernfalls wird die Anmeldung abgelehnt.
Füllen Sie anschließend die SSO-Karte auf der Integrationsseite aus:
| Feld | Was einzutragen ist |
|---|---|
| Anzeigename | Ein beliebiges Label, das Ihre Mitglieder wiedererkennen |
| Issuer URL | Issuer Ihres IdP — die URL, die /.well-known/openid-configuration bereitstellt |
| Authorization URL | Der authorization_endpoint aus diesem Discovery-Dokument |
| Client ID / Client Secret | Aus der von Ihnen registrierten Anwendung |
Das Client Secret wird verschlüsselt gespeichert und nach dem Speichern nicht mehr an den Browser zurückgegeben.
Okta
- Admin-Konsole → Applications → Create App Integration → Sign-in-Methode OIDC, Anwendungstyp Web Application
- Sign-in Redirect URI:
https://intermind.com/api/auth/sso/callback - Weisen Sie die Benutzer oder Gruppen zu, die Zugriff erhalten sollen
- Kopieren Sie die Client ID und das Client Secret
- In InterMIND: Issuer URL = Ihre Okta-Org-URL (z. B.
https://acme.okta.com, oder der Issuer Ihres Authorization Servers wiehttps://acme.okta.com/oauth2/default, falls Sie einen verwenden); Authorization URL = derauthorization_endpointaus<issuer>/.well-known/openid-configuration
Microsoft Entra ID (Azure AD)
- Entra Admin Center → App registrations → New registration
- Plattform Web, Redirect URI
https://intermind.com/api/auth/sso/callback - Certificates & secrets → New client secret — kopieren Sie den Value des Secrets sofort
- Client ID = die Application (client) ID auf der Übersichtsseite
- Stellen Sie sicher, dass das ID-Token die E-Mail des Benutzers enthält: Token configuration → Add optional claim → ID → email
- In InterMIND: Issuer URL =
https://login.microsoftonline.com/<tenant-id>/v2.0; Authorization URL =https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
Google Workspace
Keine App-Registrierung erforderlich. Wählen Sie in der SSO-Karte den Provider-Typ Google Workspace und speichern Sie — Mitglieder auf Ihren verifizierten Domains melden sich mit ihrem Google-Konto an und treten Ihrem Team automatisch bei. (Google kann alternativ als generischer OIDC-Provider mit dem Issuer https://accounts.google.com angebunden werden, wenn Sie explizite Client-Anmeldedaten bevorzugen.)
Verbindung testen
- Öffnen Sie die Login-Seite in einem privaten/Inkognito-Fenster
- Klicken Sie auf Mit SSO anmelden und geben Sie eine geschäftliche E-Mail-Adresse einer Ihrer verifizierten Domains ein
- Sie werden zu Ihrem IdP weitergeleitet; nach der Authentifizierung landen Sie angemeldet zurück in InterMIND
- Die Anmeldung wird im Team-Audit-Log (exportierbar über die Seite Users) als
auth.loginmit Methodessoprotokolliert
Fehlerbehebung
| Symptom | Ursache |
|---|---|
| „SSO ist nicht konfiguriert" nach Eingabe der E-Mail | Keine aktive SSO-Konfiguration passt zu dieser E-Mail-Domain — prüfen Sie, ob die Domain verifiziert und die SSO-Karte gespeichert ist |
SSO login is not available: plan | Der Plan des Teams beinhaltet kein SSO mehr |
SSO login is not available: domain-not-verified | Die DNS-Verifizierung der Domain steht noch aus |
SSO login is not available: config-incomplete | Client ID oder Client Secret fehlt — speichern Sie die SSO-Karte erneut |
SSO login is not available: type-unsupported | Die hinterlegte Konfiguration ist SAML — SAML-Anmeldung ist noch nicht verfügbar |
SSO IdP discovery failed | Issuer URL ist falsch oder liefert kein /.well-known/openid-configuration |
| „login session expired, start again" | Zwischen Start der Anmeldung und IdP-Callback sind mehr als 5 Minuten vergangen |
| Anmeldung nach IdP-Weiterleitung abgelehnt | Der IdP hat eine E-Mail außerhalb Ihrer verifizierten Domains oder gar keinen email-Claim geliefert (Entra: optionalen E-Mail-Claim hinzufügen) |
Sicherheitseigenschaften
Für Sicherheitsfragebögen: Der SSO-Flow ist Authorization Code mit PKCE (S256), state und nonce; die Signatur des ID-Tokens wird gegen das JWKS des IdP validiert, ebenso Issuer und Audience; der IdP ist ausschließlich für per DNS verifizierte Domains autoritativ — eine Assertion für eine andere E-Mail erzeugt nie eine Session; das OIDC-Client-Secret wird verschlüsselt gespeichert; jede SSO-Anmeldung landet im Audit-Log des Teams. Plan-, Domain- und Konfigurations-Gates werden serverseitig sowohl beim Anmeldestart als auch beim Callback durchgesetzt.