Einstellungen

Die Einstellungsseite ist über das Zahnrad-Icon in der linken Navigation erreichbar. Sie ist in fünf Kategorien gegliedert, die jeweils eine eigene Unterseite öffnen.

Kachel	Beschreibung
Branding	Anwendungslogos für Dark- und Light-Mode
Server-Einstellungen	Öffentlicher Hostname/Port und TLS-Zertifikat dieser App
Protokollierung	Log-Level, Datei-Rotation, Request/Response-Logging
IDIAL-Container-Kommunikation	Timeouts und Logging für IDIAL-Container-Requests
OpenID Connect (OIDC)	Single Sign-On über einen externen Identity Provider

---

Branding

Die Seite Branding ermöglicht es, die in der Anwendung angezeigten Logos anzupassen. Standardmäßig werden die BxC-Logos verwendet.

Über Logo hochladen können eigene Unternehmenslogos für den Dark-Mode-Logo und das Light-Mode-Logo getrennt hochgeladen werden. Wenn Ihre Anwendung nur in einem Modus betrieben wird, genügt es, nur das entsprechende Logo zu setzen.

---

Server-Einstellungen

Die Seite Server-Einstellungen enthält die zentralen Netzwerk- und TLS-Konfigurationen der IDIAL-APP.

Öffentlicher Hostname und Port

Feld	Beschreibung
Öffentlicher Hostname	DNS-Name, unter dem Clients diese App erreichen. Muss mit dem Common Name oder einem SAN im TLS-Zertifikat übereinstimmen. Wird auch zur automatischen CRL-URL-Generierung verwendet.
Öffentlicher Port	HTTPS-Port der Anwendung (Standard: 443)

Klicken Sie auf Speichern, um Hostname und Port zu übernehmen, bevor Sie ein neues TLS-Zertifikat hochladen.

Sperrprüfung

Die Sperrprüfung legt fest, wie die IDIAL-APP den Sperrstatus von TLS-Zertifikaten über CRL (Certificate Revocation List) validiert:

Option	Verhalten
Aus (nicht prüfen)	CRL-Prüfung ist deaktiviert — keine Erreichbarkeit des CRL-Servers erforderlich
Soft (Warnung bei Problemen)	CRL wird geprüft; bei Problemen (z. B. CRL-Server nicht erreichbar oder abgelaufene CRL) wird eine Warnung ausgegeben, der Betrieb wird aber nicht unterbrochen
Strikt (Fehler bei Problemen)	CRL wird streng geprüft; schlägt die Prüfung fehl, wird das Zertifikat als ungültig gewertet

Aktives Server-Zertifikat

Der Bereich Aktives Server-Zertifikat zeigt das aktuell verwendete TLS-Zertifikat mit Status-Badges, Antragsteller, Aussteller, Gültigkeitsdauer, alternativen Antragstellernamen (SAN) und dem SHA-256-Fingerabdruck.

Im Auslieferungszustand ist ein selbstsigniertes Zertifikat aktiv, das als nicht vertrauenswürdig markiert ist. Nach dem Hochladen eines gültigen PKI-Zertifikats zeigt die Ansicht App vertraut diesem Zertifikat und alle Prüfungen sind grün:

warnung

Dieser Server unterstützt kein Graceful Reload — das Anwenden eines neuen Zertifikats erfordert einen manuellen Neustart der App. Planen Sie den Zeitpunkt des Zertifikatwechsels entsprechend.

Neues TLS-Zertifikat hochladen

Im Bereich Neues TLS-Zertifikat hochladen können Sie ein PKCS12-Bundle (.p12 / .pfx) mit dem neuen Server-Zertifikat und dem privaten Schlüssel hochladen. Der Upload ist in zwei Schritten: erst prüfen, dann anwenden.

Das PKCS12 kann auf zwei Wegen übergeben werden — wählen Sie den Tab entsprechend:

• Datei — Datei direkt aus dem Dateisystem hochladen
• Base64-Text — PKCS12-Inhalt als Base64-kodierten Text einfügen

Füllen Sie anschließend das Feld PKCS12 Passwort aus und klicken Sie auf Prüfen. Die Anwendung analysiert das Zertifikat und zeigt das Prüfergebnis:

Folgende Prüfungen werden durchgeführt:

Prüfung	Bedeutung
Key-Cert-Match	Privater Schlüssel und Zertifikat passen zusammen
Kette	Die Zertifikatskette ist vollständig
Gültigkeit	Das Zertifikat ist zeitlich gültig
Scht.-Verw. (Schlüsselverwendung)	Die Schlüsselverwendung ist korrekt gesetzt
EKU	Extended Key Usage passt zur Server-Authentifizierung
SAN-Host	Der konfigurierte öffentliche Hostname ist als SAN im Zertifikat enthalten
Basic-Constr.	Basic Constraints sind korrekt gesetzt
Algorithmus	Der Signaturalgorithmus ist sicher
Quellen	Die Zertifikatsquellen konnten aufgelöst werden
Krit. Erw.	Kritische Erweiterungen sind bekannt und korrekt
Sperrstatus	Das Zertifikat ist nicht gesperrt (gemäß der konfigurierten Sperrprüfung)

Wenn alle Prüfungen bestanden sind, klicken Sie auf Anwenden. Das Zertifikat wird gespeichert und sofort aktiviert. Eine Toast-Meldung Server-Zertifikat angewendet bestätigt den Erfolg.

info

Das Zertifikat muss von einer CA ausgestellt sein, die im Trust Store der IDIAL-APP hinterlegt ist, damit die SAN-Host-Prüfung bestehen kann. Laden Sie die CA-Zertifikate daher vor dem Server-Zertifikat in den Trust Store (siehe Anleitung zur Initialisierung, Schritt 5).

---

Protokollierung

Die Seite Protokollierung steuert das Logging-Verhalten der IDIAL-APP.

Parameter	Beschreibung
Datei-Logging	Aktiviert oder deaktiviert das Schreiben von Log-Meldungen in eine Datei
Datei-Log-Level	Detailgrad des Datei-Logs: TRACE, DEBUG, INFO, WARN, ERROR (von detailliert bis knapp)
Log-Rotation	Anzahl der Tage, nach denen alte Log-Dateien archiviert werden (Standard: 30 Tage)
Konsolen-Logging	Aktiviert oder deaktiviert die Ausgabe von Log-Meldungen in die Container-Konsole
Konsolen-Log-Level	Detailgrad des Konsolen-Logs
Request/Response-Logging	Loggt alle eingehenden REST-Requests und ausgehenden Responses. Achtung: Dies kann die Logdateigröße massiv erhöhen, selbst bei höheren Log-Leveln

Änderungen werden mit Speichern übernommen.

tipp

Für den Produktivbetrieb empfehlen wir Datei-Log-Level: INFO und Konsolen-Log-Level: INFO. Das Level DEBUG erzeugt sehr große Log-Dateien und eignet sich nur zur Fehleranalyse. Das Level TRACE liefert maximale Details für tiefgehende Analysen.

---

IDIAL-Container-Kommunikation

Die Seite IDIAL-Container-Kommunikation konfiguriert das Timeout-Verhalten und Logging für die Kommunikation zwischen der IDIAL-APP und den angeschlossenen IDIAL-Containern.

Parameter	Beschreibung
Request-Timeout (Sekunden)	Timeout für alle IDIAL-Container-Requests außer dem Verbindungstest (1–300 s, Standard: 30 s)
Verbindungstest-Timeout (Sekunden)	Timeout für den systeminfo-Verbindungstest, der häufig ausgeführt wird, um den Online-Status der Container zu prüfen (1–60 s, Standard: 10 s)
IDIAL Request/Response-Logging	Loggt den gesamten HTTP-Verkehr zu und von IDIAL-Containern. Erhöht das Log-Volumen erheblich

Änderungen werden mit Speichern übernommen.

---

OpenID Connect (OIDC)

Die Seite OpenID Connect (OIDC) ermöglicht die Anbindung eines externen Identity Providers (IdP) für Single Sign-On. Benutzer können sich dann über den IdP authentifizieren und erhalten nach erfolgreicher Anmeldung Zugriff auf die IDIAL-APP.

Grundkonfiguration

Aktivieren Sie zunächst den Schalter Aktiviert oben rechts. Füllen Sie anschließend die folgenden Felder aus:

Feld	Beschreibung
Anbietername	Anzeigename des Identity Providers — wird als Beschriftung des SSO-Buttons auf der Login-Seite verwendet
Issuer-URL	Discovery-Endpunkt des IdP (z. B. https://login.microsoftonline.com/<tenant>/v2.0) — über Testen kann die Erreichbarkeit geprüft werden
Client-ID	Die Client-ID dieser Anwendung aus der IdP-Registrierung
Client-Secret	Das Client-Secret der Anwendung — leer lassen, um das aktuell gespeicherte Secret beizubehalten
Redirect-URI	Wird automatisch generiert und ist schreibgeschützt — muss als Redirect-URI in der IdP-Anwendungsregistrierung eingetragen sein
Scopes	OAuth2-Scopes, die beim Login angefordert werden (Standard: openid, profile, email)
Groups-Claim	Name des Claims im ID-Token, der Gruppenmitgliedschaften enthält (Standard: groups)
Groups-Überlauf-Verhalten	Verhalten, wenn der Groups-Claim zu viele Einträge enthält: Deny Login (Anmeldung verweigern)
Sitzungsdauer	Gültigkeitsdauer einer OIDC-Sitzung in Minuten (Standard: 60)
Just-in-Time Benutzerbereitstellung	Wenn aktiviert, werden Benutzerkonten beim ersten Login automatisch in der IDIAL-APP angelegt

Rollenzuweisungsmodus

Der Rollenzuweisungsmodus legt fest, wie IDIAL-APP-Rollen an angemeldete Benutzer vergeben werden:

• Manuell — Rollen werden ausschließlich in der Benutzerverwaltung der IDIAL-APP gepflegt. Der IdP liefert keine Rolleninformation. Dieser Modus eignet sich, wenn die Rollenverwaltung zentral im IDIAL-APP-Benutzerverzeichnis erfolgen soll.

• Automatisch (Claim-Mapping) — Rollen werden anhand von Claims im ID-Token des IdP automatisch zugewiesen. Dieser Modus empfiehlt sich, wenn Rolleninformationen bereits im IdP gepflegt werden.

Automatische Rollenzuordnung

Wenn der Modus Automatisch (Claim-Mapping) aktiv ist, erscheint die Sektion Automatische Rollenzuordnung:

Feld	Beschreibung
Claim-Name	Name des Claims im ID-Token, der die Rollenwerte enthält (z. B. roles, groups, team_access.roles)
Fallback-Rollen	Rollen, die Benutzern zugewiesen werden, wenn kein Claim-Wert einer konfigurierten Zuordnung entspricht. Bietet sich an, wenn alle authentifizierten Benutzer mindestens eine Basisrolle erhalten sollen (z. B. IDIAL User).

Unterhalb der Fallback-Rollen sind für jede IDIAL-APP-Rolle (Administrator, User Manager, IDIAL Administrator, IDIAL Operator, IDIAL User) separate Eingabefelder vorhanden. Tragen Sie jeweils die Claim-Werte ein, die der IdP für diese Rolle liefert (z. B. eine Gruppen-UUID oder einen Rollennamen). Über + Hinzufügen können mehrere Claim-Werte pro Rolle eingetragen werden.

Zuordnung testen

Am unteren Ende der Seite befindet sich der Bereich Zuordnung testen. Geben Sie dort kommagetrennte Claim-Werte ein, um einen Login zu simulieren und die resultierende Rollenzuordnung zu prüfen — ohne einen echten Anmeldevorgang durchführen zu müssen.

info

Die OIDC-Konfiguration entnehmen Sie der Dokumentation Ihres Identity Providers sowie den Angaben in der Anwendungsregistrierung. Redirect-URI und Issuer-URL müssen in der IdP-Registrierung exakt übereinstimmen.