Single Sign-on

Der SQL Server Health Monitor unterstützt OpenID-Connect-SSO neben der lokalen Anmeldung mit Benutzername und Kennwort. Beides schließt sich nicht aus — lokale Konten funktionieren weiter und dienen als Notzugang, falls der Identitätsanbieter ausfällt.

Funktioniert mit jedem standardkonformen OIDC-Anbieter: Microsoft Entra ID (früher Azure AD), Okta, Google Workspace, Keycloak, Auth0, …

Einrichtung im Überblick

Die Anwendung beim Identitätsanbieter registrieren.
Die dort erzeugte Client-ID und das Clientgeheimnis nach appsettings.json oder in die User Secrets übernehmen.
Anwendung neu starten.
Die Anmeldeseite zeigt nun eine Schaltfläche „Mit SSO anmelden“.

Optional:

Unbekannte SSO-Benutzer automatisch anlegen (Standard: ein, Rolle = Viewer).
Einen Gruppen-Claim des Identitätsanbieters auf die Rolle Admin abbilden.

Schritt für Schritt: Microsoft Entra ID

Azure-Portal → Microsoft Entra ID → App-Registrierungen → Neue Registrierung.
Name: SQL Server Health Monitor. Unterstützte Kontotypen: üblicherweise „Nur Konten in diesem Organisationsverzeichnis“.
Umleitungs-URI: Web → https://ihr-monitor-host/signin-oidc
Nach dem Anlegen:
- Anwendungs-ID (Client) und Verzeichnis-ID (Mandant) notieren.
- Unter Zertifikate & Geheimnisse → Neues Clientgeheimnis → den Wert kopieren (wird nur einmal angezeigt).
- Unter API-Berechtigungen genügt das voreingestellte User.Read; die Anwendung benötigt nur openid profile email.
(Optional, für die Abbildung der Admin-Gruppe) Unter Tokenkonfiguration → Gruppenanspruch hinzufügen → „Sicherheitsgruppen“ wählen → speichern. Damit legt Entra ID einen groups-Claim mit den Objekt-IDs der Gruppen des Benutzers in das Token.
appsettings.json bearbeiten:

{
  "OidcSettings": {
    "Enabled": true,
    "DisplayName": "Mit Entra ID anmelden",
    "Authority": "https://login.microsoftonline.com/<tenant-id>/v2.0",
    "ClientId": "<application-id>",
    "ClientSecret": "<client-secret-value>",
    "Scopes": [ "openid", "profile", "email" ],
    "AutoCreateUsers": true,
    "AdminGroupClaim": "groups",
    "AdminGroupValue": "<Objekt-ID-der-DBA-Gruppe>"
  }
}

Neu starten. Die Anmeldeseite zeigt nun „Mit Entra ID anmelden“.

Schritt für Schritt: Okta

Okta-Administration → Applications → Create App Integration → OIDC — OpenID Connect → Web Application.
Umleitungs-URI für die Anmeldung: https://ihr-monitor-host/signin-oidc
Umleitungs-URI für die Abmeldung: https://ihr-monitor-host/signout-callback-oidc
Client-ID, Clientgeheimnis und Ihre Okta-Domäne notieren.
appsettings.json bearbeiten:

{
  "OidcSettings": {
    "Enabled": true,
    "DisplayName": "Mit Okta anmelden",
    "Authority": "https://<ihre-okta-domaene>/oauth2/default",
    "ClientId": "...",
    "ClientSecret": "...",
    "Scopes": [ "openid", "profile", "email" ],
    "AutoCreateUsers": true,
    "AdminGroupClaim": "groups",
    "AdminGroupValue": "SqlMonitorAdmins"
  }
}

Richten Sie für den Gruppen-Claim im „Authorization Server“ einen eigenen Claim namens groups ein und nehmen Sie nur die Gruppen auf, die Sie wirklich brauchen — sonst wird das Token sehr groß.

Regeln für das automatische Anlegen

Wenn sich ein Benutzer zum ersten Mal per SSO anmeldet:

Die Anwendung sucht einen vorhandenen lokalen Benutzer, dessen Email oder UserName dem vom Identitätsanbieter gelieferten E-Mail-Claim entspricht. Wird einer gefunden, wird die Identität des Anbieters mit diesem lokalen Benutzer verknüpft — er kann sich von da an auf beide Arten anmelden.
Wird keiner gefunden und AutoCreateUsers ist true: Es wird ein neuer lokaler Benutzer angelegt, mit UserName = Email, EmailConfirmed = true und der Rolle Viewer. Ein Administrator kann ihn später unter /Settings/Users höherstufen.
Wird keiner gefunden und AutoCreateUsers ist false: Die Anmeldung wird mit einer Meldung abgelehnt, die den Benutzer auffordert, das Konto zuerst von einem Administrator anlegen zu lassen.

Abbildung der Administratorrolle

Das Paar AdminGroupClaim / AdminGroupValue ist optional, aber wirkungsvoll:

Bei jeder SSO-Anmeldung prüft die Anwendung, ob die Claims des Benutzers einen vom Typ AdminGroupClaim mit dem Wert AdminGroupValue enthalten.
Trifft das zu und der Benutzer ist noch nicht in der lokalen Rolle Admin → er wird höhergestuft.
Trifft es nicht zu und der Benutzer ist in der lokalen Rolle Admin → sie wird ihm entzogen.

Nimmt man also jemanden beim Identitätsanbieter aus der DBA-Gruppe heraus, verliert er hier bei der nächsten Anmeldung automatisch die Administratorrolle. Manuelles Nacharbeiten entfällt.

Um die Abbildung ganz abzuschalten, lassen Sie beide Felder leer.

Verhalten beim Abmelden

Standard: Ein Klick auf „Abmelden“ löscht nur das lokale Cookie. Der Benutzer kann danach erneut auf die SSO-Schaltfläche klicken und ist sofort wieder angemeldet, denn die Sitzung beim Identitätsanbieter besteht weiter.

Wenn Sie eine RP-initiierte Abmeldung wünschen (die auch die Sitzung beim Identitätsanbieter beendet, sodass bei der nächsten Anmeldung das Kennwort dort erneut einzugeben ist), setzen Sie OidcSettings:SignOutFromIdP auf true. Das ist nicht der Standard, weil die meisten Betriebsteams das rein lokale Verhalten bevorzugen.

Fehlerbehebung

„SSO provider did not return an email claim“

Der Benutzer hat sich erfolgreich authentifiziert, aber der Identitätsanbieter hat keinen email-Claim in das Token gelegt. Prüfen Sie:

Der Scope email wird angefordert (Standard ist openid profile email).
Der Benutzer hat beim Identitätsanbieter eine E-Mail-Adresse hinterlegt.
Bei Entra ID: Der Benutzer ist ein Mitglied, kein Gast — Gastkonten benötigen mitunter ausdrückliche Zustimmungen.

Der Anmelde-Wartekreis dreht sich endlos

Die Rückleitung des Identitätsanbieters auf /signin-oidc schlägt fehl. Prüfen Sie:

Die beim Anbieter registrierte Umleitungs-URI stimmt exakt mit der Adresse der Anwendung überein (abschließender Schrägstrich, Schema, Port).
HTTPS ist erzwungen — die meisten Anbieter lehnen HTTP-Umleitungs-URIs ab.
Zeitversatz zwischen Anwendungsrechner und Identitätsanbieter. OIDC-Token haben kurze Gültigkeitsfenster; mehr als fünf Minuten Versatz bricht die Signaturprüfung.

„Failed to provision local account: …“

Identity hat das Anlegen des Benutzers abgelehnt. Häufigste Ursache: Die E-Mail-Adresse ist ungültig oder scheitert an den konfigurierten User-Prüfungen. Verschärfen oder lockern Sie IdentityOptions.User in Program.cs.

Das vom Anbieter ausgestellte Subject war früher schon mit einem anderen lokalen Konto verknüpft. Löschen Sie entweder die verwaiste Verknüpfung direkt in AspNetUserLogins oder das doppelte lokale Konto.

SSO abschalten

Setzen Sie OidcSettings:Enabled auf false und starten Sie neu. Benutzer, die sich per SSO angemeldet haben, behalten ihre lokalen Konten und können sich weiterhin mit Benutzername und Kennwort anmelden — nachdem ein Administrator über /Settings/Users → „Kennwort zurücksetzen“ ein Kennwort gesetzt hat, denn automatisch angelegte Konten haben standardmäßig keines.