Diagnose
Folgende Punkte helfen, die Funktionsfähigkeit des CMI STS festzustellen.
OpenID-Connect Discovery
Der Endpunkt .well-known/openid-configuration
ist ein OpenID-Connect Discovery-Standardendpunkt und muss ohne Authentifizierung (Anonym) aufrufbar sein:
https://<cmi sts host>/<mandant>/identity/.well-known/openid-configuration
Diagnose und Logging mit PII-Daten
Für die Diagnose von Login-Prozessen kann es erforderlich sein, PII-Daten (Personally Identifiable Information) auswerten zu müssen. Diese Informationen werden entweder in das Log geschrieben oder auf einer Diagnostics-Seite angezeigt.
Das für den Benutzer nach der Anmeldung ausgestellte Authentication Cookie kann der Benutzer über folgenden Endpunkt angezeigt werden:
https://<cmi sts host>/<mandant>/identity/diagnostics
{
"Diagnostic": {
"RestrictDiagnosticsToLocalhost": false,
"EnableIdpIdentityDiagnostic": false,
"MsIdentityModelShowPII": false
}
}
RestrictDiagnosticsToLocalhost
(optional, Standardwert:false
): Die Diagnostics-Seite kann auf Localhost eingeschränkt werden, wenn sie nicht für jeden aufrufbar sein soll. Die Seite ist dann nur noch vom Webserver aus verfügbar.EnableIdpIdentityDiagnostic
(optional, Standardwert:false
): Beim Anmeldeprozess über einen IDP werden zusätzliche Benutzerdaten aufgezeichnet, die der IDP dem CMI STS mitgeteilt hat, auch wenn diese nicht für die korrekte Funktionsweise benötigt werden. Alle vom IDP ausgestellten Claims können auf der Diagnostics-Seite eingesehen werden. Die Benutzerdaten werden drei Stunden nach dem letzten Aufruf gelöscht.MsIdentityModelShowPII
(optional, Standardwert:false
): Standardmässig enthalten Lognachrichten, die vonMicrosoft.IdentityModel
erzeugt werden, keine PII-Daten. Zu Diagnosezwecken können diese PII-Daten in das Log geschrieben werden.
Health Check Endpunkte
Der CMI STS bietet Health-Endpunkte an:
https://<cmi sts host>/health
: Schnelle mandantenunabhängige Health-Checks.https://<cmi sts host>/<mandant>/health
: Health-Checks für einen spezifischen Mandanten.https://<cmi sts host>/health/all
: Alle Health-Checks. (Mandanten- und Mandantenunabhängige Checks)
Wichtig: Der Endpunkt /health
ist für das häufige Abfragen durch ein Monitoring-System ausgelegt. Es werden kurze und schnelle Checks ausgeführt. Alle anderen Endpunkte können teure Checks (Dauer, Systemlast) ausführen und sollten nicht permanent aufgerufen werden. Sie können jedoch eine Status-Übersicht für Diagnose-Zwecke verschaffen.
Antwortet ein Endpunkt mit dem Http-Status-Code 200, waren alle Health-Checks erfolgreich.
Die Health-Check-Endpunkte werden in HealthCheck
konfiguriert:
{
"HealthCheck":{
"RequireHost": [ "localhost" ],
"ApiKey": null,
"HttpClient": {
"UnavailableTimeoutSeconds": 20,
"SlowResponseThresholdSeconds": 10,
}
}
}
RequireHost
(optional, Standardwertlocalhost
): Legt eine Liste fest von Bindings fest, über die die Endpunkte verfügbar gemacht werden sollen. Es kann ein Host (www.domain
), ein Host mit Wildcard (*.domain.ch
), ein Port (*:5000
) oder Host und Port (www.domain.com:5000
,*.domain.com:5000
) angegeben werden. Siehe auch Host matching in routes with RequireHost.ApiKey
(optional): Ein beliebiger String. Wenn ein API Key angegeben wird, werden die Health-Checks nur ausgeführt, wenn in der Anfrage der API Key im Http-Header X-HEALTH-KEY übermittelt wird.
Für einige Health Checks werden Http-Anfragen versendet. Der Http-Client für diese Anfragen kann konfiguriert werden.
HttpClient.UnavailableTimeoutSeconds
(optional, Standardwert20
): Legt einen Timeout fest, nach dem angenommen wird, dass die Http-Anfrage fehlgeschlagen ist.HttpClient.SlowResponseThresholdSeconds
(optional, Standardwert10
): Legt einen Threshold fest, der beim Überschreiten den Health Checks als degraded betrachtet.