Start/notes.ini Parameter/DEBUG_OIDCLogin

DEBUG_OIDCLogin

Parameter: DEBUG_OIDCLogin
Kurzbeschreibung: Aktiviert detailliertes Tracing des Web-Login-mit-OIDC-Flows auf der Domino-Server-Konsole. Fünf Stufen (0–4) von deaktiviert bis maximal verbose — unverzichtbar bei der Fehlersuche von OIDC-Login-Problemen.

Steckbrief

Parameter
DEBUG_OIDCLogin
Kategorie
Logging / Debug (OIDC / Web-SSO)
Komponente
Server (HTTP-Task)
Verfügbar seit
14.0
Unterstützte Versionen
14.0, 14.5, 14.5.1
GUI-Entsprechung
Nur notes.ini (keine GUI)
Mögliche Werte
0 = Debug deaktiviert (Standard)
1 = Basis-Tracing (Login-Start, Erfolg/Fehler)
2 = Erweitertes Tracing (Redirects, Token-Anforderungen)
3 = Detailliertes Tracing inkl. Claims-Mapping
4 = Maximal-verbose: alle HTTP-Header, alle id_token-Claims, kompletter Cookie-State

Beschreibung

Der Web-Login-Flow mit OIDC umfasst mehrere Stationen: Browser ruft geschützte URL auf → Domino erkennt fehlende Session → Redirect zum OIDC-Provider → User authentifiziert sich → Provider redirected zurück mit Authorization Code → Domino tauscht Code gegen Tokens → id_token wird validiert → Claims werden gegen Domino Directory gemappt → Session-Cookie wird gesetzt → ursprüngliche URL wird ausgeliefert.
Wenn an irgendeiner Stelle dieses Flows etwas schiefgeht, ist die Ursache ohne Tracing oft schwer zu finden — die typischen Browser-Fehlermeldungen (Unable to authenticate, Authentication failed) helfen kaum. DEBUG_OIDCLogin schaltet ausführliches Logging auf der Domino-Server-Konsole ein.
Empfohlene Stufen:
  • =1 — Erste Diagnose: Wo bleibt der Login-Flow stecken? Provider-Erreichbarkeit, grundlegende Token-Antwort.
  • =2 — Wenn Stufe 1 nicht reicht: zusätzlich Redirect-Details, State-Parameter, Cookie-Setzen.
  • =3 — Wenn Authentifizierung am Provider klappt, aber Mapping ins Domino Directory fehlschlägt: zeigt verwendete Claims, Lookup-Schlüssel, Treffer/Fehlschläge.
  • =4 — Maximaltiefe: vollständige id_token-Claims (entschlüsselt), Header, Cookies. Achtung: Diese Stufe loggt sensitive Daten (Tokens, ggf. Email-Adressen) — nicht im Produktionsbetrieb dauerhaft aktivieren.

Beispiel-Konfiguration

Volländiges Tracing temporär aktivieren:
DEBUG_OIDCLogin=4
Nach Diagnose wieder deaktivieren:
DEBUG_OIDCLogin=0
Oder zur Laufzeit auf der Server-Konsole:
set config DEBUG_OIDCLogin=2

Hinweise & Stolperfallen

  • Sicherheits-Risiko bei Stufe 4: Die Konsole zeigt id_token-Claims im Klartext — inkl. Email-Adressen, Subject-IDs und ggf. Provider-Metadaten. Logfiles entsprechend schützen oder nach der Diagnose löschen.
  • Ergänzend für Redirect-Diagnose ist DEBUG_OIDC_LOGIN_REDIRECT=1 nützlich — dieser Parameter trackt nur die Auto-Redirect-Logik (OIDC_LOGIN_ENABLE_REDIRECT).
  • Für Provider-seitige Probleme zusätzlich auf der Provider-Konsole (Keycloak, Azure AD-Sign-in-Logs) prüfen — Domino kann nur sehen, was beim Server ankommt.
  • Für Probleme mit dem HTTP-Bearer-Authentication-Layer (Token-Validierung, JWKS-Endpoint) zusätzlich DEBUG_OIDC=... aktivieren (eigener Parameter für Bearer-Auth).
  • Voraussetzung: HTTP Bearer Authentication und Web-Login mit OIDC sind im betreffenden Internet Site-Dokument aktiviert.
  • Änderung wirkt sofort über set config DEBUG_OIDCLogin=… — kein HTTP-Restart nötig.
  • Funktioniert nur auf Windows- und Linux-Servern.
  • Tracing erscheint sowohl auf der Live-Konsole als auch in console.log (Domino Data Directory).

Quellen (HCL Product Documentation)