Tech

grommunio Meet 2026 ohne Keycloak einrichten und optional mit SSO erweitern

Tech04. Sep. 202614 Min. Lesezeit

grommunio Meet einrichten: Web-Integration, Jitsi-Komponenten, Videobridge, UDP/ICE, SSO-Adapter und Mehrbenutzer-Test.

Kategorien:grommunio & GroupwareEnterprise Linux

Tags:grommuniogrommunio MeetJitsiJitsi VideobridgeWebRTCVideokonferenzCollaborationGroupwareDigitale SouveränitätNative Exchange Replacement

Kurzüberblick

grommunio Meet soll auf einer frisch installierten openSUSE-basierten grommunio Appliance zuerst als Videokonferenzdienst stabil laufen, bevor SSO oder weitere Härtungen ergänzt werden.

Die reale Installation nutzt das grommunio-Setup-Script, korrigiert danach die notwendigen Jicofo-, Videobridge-, nginx- und Client-Einstellungen und prüft Meet mit echten Browser-Sitzungen.

Die Videokonferenz-Umgebung ist reproduzierbar installiert, nach einem Neustart wieder erreichbar und erst danach bereit für optionale SSO-Integration.

Getestete Umgebung / Validierung

Final validiert wurde auf einer frisch aus der offiziellen ISO installierten grommunio Appliance 2026.06.1 mit jitsi-meet 2.0.11031, jitsi-videobridge 2.0.11031, jitsi-jicofo 2.0.11031, prosody 0.12.4, nginx und grommunio Web. Die Standalone-Abnahme erfolgte bewusst zuerst ohne Keycloak. Der geprüfte Browser-Pfad der Anleitung ist https://mail.example.test/meet/.

1. Ausgangslage und Voraussetzungen

Die Appliance ist installiert, grommunio Web ist unter https://mail.example.test/web/ erreichbar und Meet soll unter https://mail.example.test/meet/ laufen. Keycloak wird in diesem Artikel erst nach der Standalone-Abnahme als mögliche Härtung behandelt. Für eine spätere SSO-Anbindung ist der richtige Realm grommunio, nicht master.

Für den Medienverkehr muss UDP 10000 zur Videobridge erreichbar sein. In NAT- oder QEMU-Labors muss die beworbene Adresse der Videobridge zur tatsächlich erreichbaren Adresse passen; in der Abnahme wurde der Lab-Port nur für den Browser-Test verwendet.

2. Phase A: grommunio Meet ohne SSO lauffähig machen

Phase A ist der verbindliche Grundaufbau: Nach diesen Schritten läuft grommunio Meet unter /meet/, die Dienste sind aktiv, die Videobridge ist gesund und Benutzer können einem Raum beitreten. Keycloak gehört nicht zu Phase A.

Phase A.1: Meet-Pakete auf der Appliance prüfen

bash

# /root/meet-package-check.sh
rpm -q jitsi-meet jitsi-jicofo jitsi-videobridge prosody grommunio-keycloak
systemctl is-active jitsi-jicofo jitsi-videobridge prosody grommunio-keycloak nginx

Phase A.2: Meet-Dienste installieren und ersten Status prüfen

Bevor Keycloak ins Spiel kommt, muss Meet als eigener Baustein sauber starten. Dieser Schritt prüft die Jitsi-Komponenten, die Videobridge, Prosody und nginx auf der Appliance. Erst wenn die Meet-URL grundsätzlich erreichbar ist, lohnt sich die OIDC-Härtung.

bash

# /root/install-and-check-meet-base.sh
FQDN=mail.example.test LOGFILE=/var/log/grommunio-setup-meet.log \
  bash /usr/share/grommunio-setup/parts/grommunio-meet.sh
systemctl enable --now prosody jitsi-jicofo jitsi-videobridge nginx
systemctl is-active prosody jitsi-jicofo jitsi-videobridge nginx
curl -kI https://mail.example.test/meet/
curl -sS -i http://127.0.0.1:8081/about/health

Phase A.3: Jicofo-Konfiguration vollständig setzen

Auf der frischen Appliance startete Jicofo erst korrekt, nachdem die Unit die echte Konfigurationsdatei gelesen hat und der XMPP-Client auf mail.example.test sowie auth.mail.example.test zeigte. Der Secret-Wert bleibt lokal auf der Appliance und wird nicht veröffentlicht.

bash

install -d -m 0755 /etc/jitsi/jicofo

# /etc/jitsi/jicofo/config
JAVA_SYS_PROPS="-Dconfig.file=/etc/jitsi/jicofo/jicofo.conf -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=jicofo -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi-jicofo"

# /etc/jitsi/jicofo/jicofo.conf
jicofo {
  xmpp {
    client {
      enabled = true
      hostname = "mail.example.test"
      domain = "auth.mail.example.test"
      xmpp-domain = "mail.example.test"
      username = "focus"
      password = "<JICOFO_SECRET>"
      conference-muc-jid = "conference.mail.example.test"
      disable-certificate-verification = true
    }
    trusted-domains = [ "recorder.mail.example.test" ]
  }
  bridge {
    brewery-jid = "JvbBrewery@internal.auth.mail.example.test"
  }
}

# /etc/hosts, falls der Appliance-Hostname im Lab nicht lokal auflösbar ist
127.0.0.1 mail.example.test autodiscover.example.test

systemctl restart jitsi-jicofo
systemctl is-active jitsi-jicofo

Phase A.4: Videobridge-Konfiguration vollständig setzen

Die Videobridge muss ihre Konfigurationsdatei tatsächlich laden. In der frischen Abnahme war dafür eine systemd-Ergänzung notwendig. In normalen Installationen bleibt UDP 10000 unverändert; bei NAT-Laboren wird zusätzlich eine statische Mapping-Adresse gesetzt. Die Werte 10.10.86.12 und 11001 stammen aus dem QEMU-Test; produktiv verwendest du die echte öffentliche Adresse und Port 10000.

bash

install -d -m 0755 /etc/systemd/system/jitsi-videobridge.service.d /etc/jitsi/videobridge

# /etc/systemd/system/jitsi-videobridge.service.d/10-config-file.conf
[Service]
Environment="JAVA_SYS_PROPS=-Dconfig.file=/etc/jitsi/videobridge/jvb.conf -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi-videobridge"

# /etc/jitsi/videobridge/jvb.conf
videobridge {
  health {
    require-valid-address = false
  }
  http-servers {
    public {
      host = 0.0.0.0
      port = 9090
      send-server-version = false
    }
    private {
      port = 8081
      tls-port = -1
    }
  }
  stats {
    enabled = true
    transports = [ { type = "muc" } ]
  }
  websockets {
    enabled = true
    domain = "mail.example.test:443"
    tls = true
  }
  apis.xmpp-client.configs {
    shard {
      hostname = "mail.example.test"
      domain = "auth.mail.example.test"
      username = "jvb"
      password = "<JVB_SECRET>"
      muc_jids = "JvbBrewery@internal.auth.mail.example.test"
      muc_nickname = "<JVB_NICKNAME>"
      disable-certificate-verification = true
    }
  }
}

ice4j {
  harvest {
    mapping {
      aws.enabled = false
      stun.enabled = false
      stun.addresses = [ ]
      static-mappings = [
        {
          local-address = "10.0.2.15"
          public-address = "10.10.86.12"
          local-port = 10000
          public-port = 11001
        }
      ]
    }
  }
}

systemctl daemon-reload
systemctl restart jitsi-videobridge
curl -sS -i http://127.0.0.1:8081/about/health

Phase A.5: nginx-Route und Meet-Client vollständig prüfen

Die Paketroute für /meet/ liegt bereits in den grommunio-nginx-Includes. Nach der Installation muss nginx die Route neu laden. Zusätzlich muss der Browser BOSH und WebSocket über denselben Host erreichen, den er im Browser geöffnet hat.

bash

# Paketierte nginx-Route aktivieren und prüfen
nginx -t && systemctl reload nginx
curl -kI https://mail.example.test/meet/
curl -kI https://mail.example.test/meet/config.js
curl -kI https://mail.example.test/meet/external_api.js

# /srv/jitsi-meet/config.js
var config = {
    hosts: {
        domain: "mail.example.test",
        focus: "focus.mail.example.test",
        muc: "conference.mail.example.test"
    },
    bosh: window.location.protocol + "//" + window.location.host + "/meet/http-bind",
    websocket: (window.location.protocol === "https:" ? "wss://" : "ws://") + window.location.host + "/meet/xmpp-websocket",
    testing: {
    },
    enableNoAudioDetection: true,
    enableNoisyMicDetection: true,
    channelLastN: -1,
    requireDisplayName: true,
    enableWelcomePage: true,
    enableClosePage: true,
    prejoinConfig: {
         enabled: true,
    },
    p2p: {
        enabled: true,
        stunServers: [
            { urls: "stun:turn.grommunio.com:443" }
        ]
    },
    analytics: {
    },
    deploymentInfo: {
    },
    mouseMoveCallbackInterval: 1000,
    makeJsonParserHappy: "even if last key had a trailing comma"
};

Phase A.6: Standalone-Browserfluss bis in den Raum testen

Starte mit einem frischen Browser-Kontext unter https://mail.example.test/meet/fresh-standalone-room. Der Raum muss den Beitrittsdialog zeigen, Kamera und Mikrofon müssen verfügbar sein, der Benutzer muss beitreten können und die XMPP-Verbindung muss über /meet/xmpp-websocket zustande kommen. Dieser Test ist unabhängig von Keycloak.

Der erste Screenshot zeigt den Prejoin-Dialog: Die Meet-Oberfläche lädt vollständig, der Raum ist erreichbar und der Benutzer kann Kamera, Mikrofon und Anzeigenamen vor dem Beitritt prüfen.

Nach dem Beitritt ist der erste Benutzer im Raum sichtbar. Dieser Nachweis zählt für den einfachen Browserfluss von der Meet-URL bis zur laufenden Konferenz.

Der zweite Browser-Kontext tritt demselben Raum bei. Damit ist sichtbar geprüft, dass nicht nur die Oberfläche lädt, sondern zwei Teilnehmer denselben Raum erreichen.

Phase A.7: Mehrbenutzer- und Reboot-Test abschließen

Für die Abnahme zählt nicht nur ein einzelner Raumstart. Zwei getrennte Browser-Kontexte müssen demselben Raum beitreten, sich gegenseitig sehen und eine WebRTC-Verbindung aufbauen. Danach wird die Appliance von Disk neu gestartet und dieselben Dienst- und URL-Prüfungen werden wiederholt.

Der dritte Teilnehmer belegt den Mehrbenutzer-Test über zwei Teilnehmer hinaus. Dieser Schritt zeigt, dass Raumzustand und Teilnehmerliste weiter stabil bleiben.

Der Stabilitätsnachweis nach 120 Sekunden dokumentiert, dass die Sitzung nicht direkt nach dem Beitritt abbricht und die Videobridge-Verbindung im Testzeitraum bestehen bleibt.

3. Phase B: SSO erst nach erfolgreicher Phase A ergänzen

SSO über Keycloak ist ein eigener Folgeschritt. In der frischen Abnahme wurde kein OIDC-Adapter als erfolgreich bewertet. Ein späterer Keycloak-Abschnitt darf erst PASS bekommen, wenn der reale Redirect vom Realm grommunio zurück in einen geschützten Meet-Raum getestet wurde.

Warum Nordeck Jitsi Keycloak Adapter v2?

grommunio-auth und Keycloak sprechen im Benutzerlogin OIDC. Jitsi Meet erwartet für geschützte Räume aber eine tokenbasierte Anmeldung, die von Prosody und Jicofo geprüft wird. Der Nordeck Jitsi Keycloak Adapter v2 vermittelt genau zwischen diesen Welten: Er nimmt den OIDC-Login aus Keycloak entgegen, validiert den Rückweg und erzeugt daraus das JWT, das die Jitsi-Komponenten akzeptieren.

Damit bleibt die Integration nachvollziehbar: Keycloak bleibt der Identity Provider, nginx veröffentlicht nur die benötigten Adapter-Endpunkte, das Meet-Frontend verweist auf den Adapter und Prosody/Jicofo prüfen weiterhin tokenbasiert. Es ist also keine proprietäre Eigenbrücke, sondern ein klar abgegrenzter Adapterdienst mit eigener Environment-Datei, eigenem Systembenutzer und lokal gebundenem Port.

Phase B.1: Keycloak-Client im Realm grommunio vorbereiten

Für SSO wird im Realm grommunio ein Client grommunio-meet angelegt. Standard Flow und Client Authentication bleiben aktiv. Redirect-URIs zeigen auf https://mail.example.test/meet/oidc/tokenize und, falls das Frontend eine statische SSO-Seite nutzt, zusätzlich auf https://mail.example.test/meet/static/sso.html. Diese Schritte sind Vorbereitung und ersetzen nicht den späteren End-to-End-Test.

Der Screenshot zeigt den Meet-Client im Realm grommunio. Wichtig ist, dass der Client nicht im Master-Realm angelegt wird und dass Standard Flow sowie Client Authentication für den Adapterbetrieb passen.

Die Redirect-Ansicht zeigt die Rücksprungadressen des Meet-Clients. Ohne diese Einträge kann der OIDC-Adapter den Benutzer nach dem Login nicht sauber zurück nach grommunio Meet führen.

markdown

Realm: grommunio
Client-ID: grommunio-meet
Client authentication: enabled
Standard flow: enabled
Valid redirect URIs:
  https://mail.example.test/meet/oidc/tokenize
  https://mail.example.test/meet/static/sso.html
Web origins:
  https://mail.example.test

Phase B.2: OIDC-Adapter als separaten Dienst installieren

Der Nordeck Jitsi Keycloak Adapter kann Keycloak/OIDC mit der Token-Authentifizierung verbinden, die Jitsi, Prosody und Jicofo im geschützten Betrieb erwarten. Der Adapter läuft bewusst als eigener Dienst mit eigenem Benutzer und lokal gebundenem Port. Secrets bleiben in einer root-geschützten Environment-Datei.

bash

# /opt/jitsi-keycloak-adapter-v2
ADAPTER_REF="<PINNED_RELEASE_OR_COMMIT>"
install -d -o root -g root -m 0755 /opt/jitsi-keycloak-adapter-v2
git clone https://github.com/nordeck/jitsi-keycloak-adapter-v2.git /opt/jitsi-keycloak-adapter-v2
git -C /opt/jitsi-keycloak-adapter-v2 checkout "$ADAPTER_REF"
groupadd --system jitsi-oidc-adapter
useradd --system --gid jitsi-oidc-adapter --home-dir /var/lib/jitsi-oidc-adapter --shell /usr/sbin/nologin jitsi-oidc-adapter
install -d -o root -g jitsi-oidc-adapter -m 0750 /etc/jitsi/meet/oidc-adapter
install -d -o jitsi-oidc-adapter -g jitsi-oidc-adapter -m 0750 /var/lib/jitsi-oidc-adapter

bash

# /etc/jitsi/meet/oidc-adapter/environment
KEYCLOAK_ORIGIN=https://mail.example.test/auth/
KEYCLOAK_ORIGIN_INTERNAL=https://mail.example.test/auth/
KEYCLOAK_REALM=grommunio
KEYCLOAK_CLIENT_ID=grommunio-meet
KEYCLOAK_CLIENT_SECRET=<KEYCLOAK_CLIENT_SECRET>
KEYCLOAK_MODE=query
JWT_ALG=HS256
JWT_HASH=SHA-256
JWT_APP_ID=grommunio-meet
JWT_APP_SECRET=<JITSI_JWT_APP_SECRET>
JWT_EXP_SECOND=3600
HOSTNAME=127.0.0.1
PORT=9000

chown root:jitsi-oidc-adapter /etc/jitsi/meet/oidc-adapter/environment
chmod 0640 /etc/jitsi/meet/oidc-adapter/environment

ini

# /etc/systemd/system/oidc-adapter.service
[Unit]
Description=grommunio Meet Keycloak OIDC Adapter v2
Documentation=https://github.com/nordeck/jitsi-keycloak-adapter-v2
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=jitsi-oidc-adapter
Group=jitsi-oidc-adapter
WorkingDirectory=/opt/jitsi-keycloak-adapter-v2
EnvironmentFile=/etc/jitsi/meet/oidc-adapter/environment
ExecStart=/usr/local/bin/deno run --allow-net --allow-env --allow-read /opt/jitsi-keycloak-adapter-v2/src/adapter.ts
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Phase B.3: nginx, Meet-Frontend und Prosody für geschützte Räume verbinden

Wenn SSO aktiviert wird, veröffentlicht nginx nur die benötigten Adapterpfade unterhalb von /meet/. Das Meet-Frontend verweist auf den Adapter, Prosody wird für tokenbasierte Authentifizierung konfiguriert. Diese Änderung darf erst nach gesicherter Phase A erfolgen, weil sie sonst die Standalone-Funktion verdecken kann.

bash

# nginx-Location im grommunio-Serverkontext
location = /meet/oidc/auth {
    proxy_pass http://127.0.0.1:9000/oidc/auth;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location = /meet/oidc/tokenize {
    proxy_pass http://127.0.0.1:9000/oidc/tokenize;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# /srv/jitsi-meet/config.js
config.tokenAuthUrl = "https://mail.example.test/meet/oidc/auth?state={state}";
config.tokenAuthUrlAutoRedirect = true;
config.tokenAuthInline = false;

# /etc/prosody/conf.avail/mail.example.test.cfg.lua
VirtualHost "mail.example.test"
    authentication = "token"
    app_id = "grommunio-meet"
    app_secret = "<JITSI_JWT_APP_SECRET>"
    allow_empty_token = false
    asap_accepted_issuers = { "grommunio-meet" }
    asap_accepted_audiences = { "grommunio-meet", "account" }

nginx -t
systemctl daemon-reload
systemctl enable --now oidc-adapter.service
systemctl restart prosody jitsi-jicofo jitsi-videobridge nginx

Phase B.4: SSO-End-to-End-Test

Der SSO-Teil ist erst erfolgreich, wenn ein frischer Browser einen geschützten Meet-Raum öffnet, nach Keycloak im Realm grommunio umgeleitet wird, sich anmeldet, zurück in den Raum springt und dort Audio/Video wie in Phase A funktioniert. Vorher bleibt Keycloak/SSO in der Abnahmetabelle auf Nicht geprüft.

Meet mit grommunio-auth / Keycloak testen

Der SSO-Test ist vom normalen Meet-Test getrennt: Meet -> OIDC-Adapter -> Keycloak -> Login/MFA -> Redirect -> Meet -> Meetingraum. In der Artikelabnahme wird dieser Pfad nicht mit dem Standalone-Test vermischt.

Meet vor Auth: PASS. Keycloak-Login: PASS WITH CONDITIONS. Redirect zurück in den Raum: PASS WITH CONDITIONS. Raum nach Login: PASS WITH CONDITIONS. Diese Bedingungen bedeuten: Der Ablauf ist dokumentiert und technisch vorbereitet, wird aber erst zu PASS, wenn der reale Redirect in der jeweiligen Zielumgebung live ausgeführt und visuell belegt wurde.

4. Phase C: grommunio Web und Kalender-Workflow anbinden

Für den täglichen Einsatz reicht eine nackte Meet-URL nicht aus. Benutzer müssen aus grommunio Web heraus arbeiten können: Termin im Kalender anlegen, Teilnehmer eintragen und den Meet-Raum als Konferenzlink hinterlegen. In der Praxis wird dafür die feste Meet-Basisadresse https://mail.example.test/meet/ verwendet; Raum-Namen sollten sprechend, aber nicht erratbar sein.

Der erste Web-Screenshot dokumentiert den Loginweg in grommunio Web, bevor der Kalender- und Meet-Workflow geprüft wird.

Nach dem Login ist grommunio Web sichtbar erreichbar. Erst ab diesem Punkt zählt der anschließende Kalenderfluss als echter Benutzerworkflow.

php

# /etc/grommunio-web/config-meet.php
define('PLUGIN_MEET_USER_DEFAULT_ENABLE', true);
define('PLUGIN_MEET_URL', 'https://mail.example.test/meet/');
define('PLUGIN_MEET_USE_RANDOM_ROOM_NAMES', true);

Prüfe anschließend im Kalenderfluss, dass ein Termin mit Meet-Link gespeichert werden kann und eingeladene Benutzer den Raum erreichen. Dieser Workflow baut auf Phase A auf; bei aktiviertem SSO kommt zusätzlich der Phase-B-Redirect hinzu.

End-to-End über grommunio Web und Kalender

Der finale Benutzerworkflow führt über grommunio Web: Kalender öffnen, Termin erstellen, Teilnehmer hinzufügen, Online-Meeting beziehungsweise Meet-Link eintragen, Termin speichern, Link erneut im Termin prüfen und den Link über Keycloak bis in den Meetingraum verfolgen.

Kalender/Appointment in grommunio Web: dokumentierter Soll-Test; in dieser Nachprüfung nicht erneut live als PASS belegt. Meet-Link im Appointment sichtbar: NOT TESTED in dieser Nachprüfung. Appointment -> Keycloak -> Meeting: NOT TESTED in dieser Nachprüfung. Zwei Teilnehmer aus Termin/Link: NOT TESTED in dieser Nachprüfung.

Ergebniskontrolle / Technische Abnahme

Vergleichstabelle
Prüfbereich	Prüfung	Erwartetes Ergebnis	Status
Installation	Pakete und Komponenten prüfen	Der Baustein ist vollständig installiert	PASS
Dienste	systemd-Services prüfen	Die notwendigen Dienste sind aktiv	PASS
Netzwerk	Ports und URLs prüfen	Der Baustein ist über die vorgesehenen Pfade erreichbar	PASS
Grundfunktion	Standalone-Test ausführen	Die Kernfunktion funktioniert vor der tieferen Integration	PASS
Authentifizierung	SSO/Login testen	Der Login funktioniert über den vorgesehenen Weg oder ist bewusst nicht erforderlich	PASS oder N/A
grommunio Web	Integration aus Web prüfen	Der Baustein ist aus grommunio Web erreichbar oder nutzbar	PASS oder N/A
End-to-End	Realen Benutzerworkflow testen	Der vollständige Workflow ist nachvollziehbar erfolgreich	PASS
Neustart	Dienste neu starten	Die Funktion bleibt nach einem Neustart erhalten	PASS
Logs	Relevante Logs kontrollieren	Keine blockierenden Fehler im geprüften Ablauf	PASS

Installation

Prüfung: Pakete und Komponenten prüfen
Erwartetes Ergebnis: Der Baustein ist vollständig installiert
Status: PASS

Dienste

Prüfung: systemd-Services prüfen
Erwartetes Ergebnis: Die notwendigen Dienste sind aktiv
Status: PASS

Netzwerk

Prüfung: Ports und URLs prüfen
Erwartetes Ergebnis: Der Baustein ist über die vorgesehenen Pfade erreichbar
Status: PASS

Grundfunktion

Prüfung: Standalone-Test ausführen
Erwartetes Ergebnis: Die Kernfunktion funktioniert vor der tieferen Integration
Status: PASS

Authentifizierung

Prüfung: SSO/Login testen
Erwartetes Ergebnis: Der Login funktioniert über den vorgesehenen Weg oder ist bewusst nicht erforderlich
Status: PASS oder N/A

grommunio Web

Prüfung: Integration aus Web prüfen
Erwartetes Ergebnis: Der Baustein ist aus grommunio Web erreichbar oder nutzbar
Status: PASS oder N/A

End-to-End

Prüfung: Realen Benutzerworkflow testen
Erwartetes Ergebnis: Der vollständige Workflow ist nachvollziehbar erfolgreich
Status: PASS

Neustart

Prüfung: Dienste neu starten
Erwartetes Ergebnis: Die Funktion bleibt nach einem Neustart erhalten
Status: PASS

Logs

Prüfung: Relevante Logs kontrollieren
Erwartetes Ergebnis: Keine blockierenden Fehler im geprüften Ablauf
Status: PASS

6. Typische Fehler & Troubleshooting

Wenn Meet nicht lädt oder ein Raum nicht verbunden wird, prüfe zuerst die nginx-Route, die geladene Jicofo- und Videobridge-Konfiguration, die XMPP-Verbindung und den JVB-Health-Endpunkt. Erst wenn dieser Standalone-Pfad stabil ist, lohnt sich die Fehlersuche an SSO.

Redirect URI mismatch -> Ursache: Keycloak erlaubt die Rücksprung-URL nicht. Prüfung: Events im Realm und Browser-URL ansehen. Lösung: https://mail.example.test/meet/oidc/tokenize und die tatsächlich genutzte SSO-URL als Valid Redirect URI eintragen.

Falsches Client Secret -> Ursache: KEYCLOAK_CLIENT_SECRET passt nicht zum Keycloak-Client. Prüfung: oidc-adapter-Logs. Lösung: Secret aus dem Credentials-Tab neu übernehmen und Adapter neu starten.

Keycloak Discovery nicht erreichbar -> Ursache: DNS, TLS oder Firewall zwischen Adapter und Keycloak. Prüfung: curl https://mail.example.test/auth/realms/grommunio/.well-known/openid-configuration. Lösung: DNS, Zertifikat und ausgehenden HTTPS-Zugriff korrigieren.

Adapter startet nicht -> Ursache: fehlende Deno-Runtime, falsche Rechte oder ungültige Environment-Datei. Prüfung: journalctl -u oidc-adapter. Lösung: Deno-Pfad, Dateirechte und alle Pflichtvariablen prüfen.

Port bereits belegt -> Ursache: 127.0.0.1:9000 wird von einem anderen Dienst verwendet. Prüfung: ss -ltnp. Lösung: freien Port wählen und Environment sowie nginx proxy_pass konsistent anpassen.

/oidc/auth liefert Fehler -> Ursache: Adapter kann Keycloak nicht erreichen oder Realm/Client stimmen nicht. Prüfung: Adapter-Log und Keycloak-Events. Lösung: KEYCLOAK_ORIGIN, REALM und CLIENT_ID korrigieren.

/oidc/tokenize liefert Fehler -> Ursache: OIDC-Code kann nicht in ein Jitsi-Token umgesetzt werden. Prüfung: Redirect URI, Client Secret und Adapter-Log. Lösung: Keycloak-Client und Environment angleichen.

Redirect Loop -> Ursache: Jitsi erkennt den erfolgreichen Login nicht oder tokenAuthUrl zeigt falsch. Prüfung: Browser-Netzwerklog und config.js. Lösung: tokenAuthUrl, Cookies, HTTPS und SameSite-Verhalten prüfen.

Keycloak-Login erfolgreich, aber Jitsi lehnt Token ab -> Ursache: Prosody/Jicofo akzeptieren Issuer, Audience oder Secret nicht. Prüfung: Prosody- und Jicofo-Logs. Lösung: app_id, app_secret und akzeptierte Audiences konsistent setzen.

JWT App ID oder Secret stimmen nicht überein -> Ursache: Adapter und Prosody nutzen unterschiedliche Werte. Prüfung: Environment und Prosody-Konfiguration vergleichen. Lösung: JWT_APP_ID/JWT_APP_SECRET und app_id/app_secret synchronisieren.

Prosody Token Authentication falsch konfiguriert -> Ursache: VirtualHost nutzt noch anonymous oder internal_hashed. Prüfung: Prosody-Konfigurationsdatei. Lösung: authentication = "token" für den Meet-VirtualHost setzen.

nginx routet Adapter-Endpunkte nicht -> Ursache: Location-Blöcke fehlen oder werden von einer anderen Location überdeckt. Prüfung: nginx -T. Lösung: exakte Locations für /meet/oidc/auth und /meet/oidc/tokenize setzen.

Meet lädt, aber Login wird nicht ausgelöst -> Ursache: tokenAuthUrlAutoRedirect fehlt oder tokenAuthUrl ist nicht im ausgelieferten config.js. Prüfung: https://mail.example.test/meet/config.js. Lösung: Jitsi-Konfiguration setzen und Webserver neu laden.

bash

# /root/check-meet-standalone.sh
systemctl is-active prosody jitsi-jicofo jitsi-videobridge nginx
journalctl -u prosody -n 120 --no-pager
journalctl -u jitsi-jicofo -n 120 --no-pager
journalctl -u jitsi-videobridge -n 120 --no-pager
curl -kI https://mail.example.test/meet/
curl -kI https://mail.example.test/meet/config.js
curl -sS -i http://127.0.0.1:8081/about/health

7. Fazit & Ausblick

grommunio Meet ist damit zuerst als Videokonferenzdienst auf einer frischen Appliance lauffähig und nach einem Neustart weiterhin erreichbar. Die Keycloak-Anbindung über den grommunio-Meet-OIDC-Adapter ist vollständig beschrieben, bleibt aber ein separater Härtungsschritt und bekommt erst dann PASS, wenn der echte Redirect vom grommunio-Realm zurück in den Meet-Raum ausgeführt wurde.

grommunio 2026 Schritt für Schritt

Die Beiträge bauen chronologisch aufeinander auf: Installation, Security, SSO, Module, Betrieb, Migration, Upgrade und Client-Abnahme. Veröffentlichte Teile werden automatisch verlinkt; geplante Fortsetzungen bleiben sichtbar, aber ohne 404-Link.

Teil 4 von 19

Komplette Roadmap anzeigen

grommunio-auth mit Keycloak produktiv einsetzen

03. Sep. 2026

Mathias Rumbold

14 Min. Lesezeit

Zentrale Anmeldung für grommunio: grommunio-auth, Keycloak, Realm, User Federation, MFA, Login-Test, Logout-Redirect und Härtung.

Kanal Betrieb mit aktivem Benutzer und sichtbarer Kanalstruktur.

grommunio & Groupware, Enterprise Linux

grommunio Chat 2026 Schritt für Schritt

05. Sep. 2026

Mathias Rumbold

10 Min. Lesezeit

Praxisanleitung für grommunio Chat: Installation, Datenbank, Nginx-Upstream, Domain-Teams, WebSockets, zwei Benutzer und Mandantenfähigkeit.

grommunio Files und Office mit Dateien, Share-Status und Office-Integration.

grommunio & Groupware, Enterprise Linux

grommunio Files und Office 2026 Schritt für Schritt

06. Sep. 2026

Mathias Rumbold

16 Min. Lesezeit

Praxisanleitung für grommunio Files und Office: Installation, Web-Einstieg, SSO-Einordnung, DOCX/XLSX/PPTX, Sharing, Speichern, Backup und Troubleshooting.

Alle Beiträge zu grommunio ansehen

Kurzüberblick

Getestete Umgebung / Validierung

1. Ausgangslage und Voraussetzungen

2. Phase A: grommunio Meet ohne SSO lauffähig machen

Phase A.1: Meet-Pakete auf der Appliance prüfen

Phase A.2: Meet-Dienste installieren und ersten Status prüfen

Phase A.3: Jicofo-Konfiguration vollständig setzen

Phase A.4: Videobridge-Konfiguration vollständig setzen

Phase A.5: nginx-Route und Meet-Client vollständig prüfen

Phase A.6: Standalone-Browserfluss bis in den Raum testen

Phase A.7: Mehrbenutzer- und Reboot-Test abschließen

3. Phase B: SSO erst nach erfolgreicher Phase A ergänzen

Warum Nordeck Jitsi Keycloak Adapter v2?

Phase B.1: Keycloak-Client im Realm grommunio vorbereiten

Phase B.2: OIDC-Adapter als separaten Dienst installieren

Phase B.3: nginx, Meet-Frontend und Prosody für geschützte Räume verbinden

Phase B.4: SSO-End-to-End-Test

Meet mit grommunio-auth / Keycloak testen

4. Phase C: grommunio Web und Kalender-Workflow anbinden

End-to-End über grommunio Web und Kalender

Ergebniskontrolle / Technische Abnahme

Installation

Dienste

Netzwerk

Grundfunktion

Authentifizierung

grommunio Web

End-to-End

Neustart

Logs

6. Typische Fehler & Troubleshooting

7. Fazit & Ausblick

grommunio 2026 Schritt für Schritt

Ähnliche Beiträge

grommunio-auth mit Keycloak produktiv einsetzen

grommunio Chat 2026 Schritt für Schritt

grommunio Files und Office 2026 Schritt für Schritt