Tech

Set up grommunio Meet 2026 without Keycloak and optionally add SSO

TechSep 04, 202614 min read

Set up grommunio Meet: web integration, Jitsi components, Videobridge, UDP/ICE, SSO adapter and multi-user test.

Categories:grommunio & Groupware

Tags:grommuniogrommunio MeetJitsiJitsi VideobridgeWebRTCVideo conferencingCollaborationGroupwareDigital SovereigntyNative Exchange Replacement

Overview

grommunio Meet must first run as a stable video conferencing service on a freshly installed openSUSE-based grommunio appliance before SSO or further hardening is added.

The real installation uses the grommunio setup script, then fixes the required Jicofo, videobridge, nginx and client settings and validates Meet with real browser sessions.

The video conferencing environment is installed reproducibly, remains reachable after restart and is only then ready for optional SSO integration.

Tested Environment / Validation

Finally validated on a fresh grommunio appliance 2026.06.1 installed from the official ISO with jitsi-meet 2.0.11031, jitsi-videobridge 2.0.11031, jitsi-jicofo 2.0.11031, prosody 0.12.4, nginx and grommunio Web. The standalone acceptance was deliberately performed without Keycloak first. The tested browser path is https://mail.example.test/meet/.

1. Starting Point and Requirements

The appliance is installed, grommunio Web is reachable at https://mail.example.test/web/ and Meet should run at https://mail.example.test/meet/. Keycloak is covered only after the standalone acceptance as a possible hardening step. For a later SSO integration, the correct realm is grommunio, not master.

UDP 10000 must be reachable for media traffic to the videobridge. In NAT or QEMU labs, the address advertised by the videobridge must match the address that the browser can actually reach; the lab port used in this validation is only a test-environment detail.

2. Phase A: Make grommunio Meet work without SSO

Phase A is the mandatory base build: after these steps grommunio Meet runs below /meet/, the services are active, the videobridge is healthy and users can join a room. Keycloak is not part of Phase A.

Phase A.1: Check Meet packages on the appliance

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: Install Meet services and check the first status

Before Keycloak is added, Meet has to start cleanly as its own component. This step checks the Jitsi components, the videobridge, Prosody and nginx on the appliance. Only after the Meet URL is reachable does the OIDC hardening make sense.

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: Set the complete Jicofo configuration

On the fresh appliance, Jicofo only started correctly after the unit read the real configuration file and the XMPP client pointed to mail.example.test and auth.mail.example.test. The secret value stays local on the appliance and is not published.

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 if the appliance name is not locally resolvable in the lab
127.0.0.1 mail.example.test autodiscover.example.test

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

Phase A.4: Set the complete videobridge configuration

The videobridge must actually load its configuration file. In the fresh validation this required a systemd drop-in. In normal installations UDP 10000 remains unchanged; NAT labs additionally need a static mapping address. The values 10.10.86.12 and 11001 are from the QEMU test; production uses the real public address and 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: Check the complete nginx route and Meet client

The package route for /meet/ already exists in the grommunio nginx includes. After installation, nginx must reload the route. The browser also needs to reach BOSH and WebSocket through the same host it opened in the address bar.

bash

# Activate and check the packaged nginx route
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: Test the standalone browser flow into the room

Start with a fresh browser context at https://mail.example.test/meet/fresh-standalone-room. The room must show the prejoin dialog, camera and microphone must be available, the user must be able to join and the XMPP connection must use /meet/xmpp-websocket. This test is independent of Keycloak.

The first screenshot shows the prejoin dialog: the Meet interface loads completely, the room is reachable and the user can check camera, microphone and display name before joining.

After joining, the first user is visible in the room. This proves the simple browser path from the Meet URL into a running conference.

The second browser context joins the same room. This verifies visibly that the interface is not merely loading, but that two participants can reach the same room.

Phase A.7: Finish the multi-user and reboot test

Acceptance requires more than a single room start. Two separate browser contexts must join the same room, see each other and establish a WebRTC connection. Afterwards, boot the appliance from disk and repeat the same service and URL checks.

The third participant proves the multi-user test beyond two participants. This step shows that the room state and participant list remain stable.

The 120-second stability screenshot documents that the session does not drop immediately after joining and that the videobridge connection remains available during the test window.

3. Phase B: Add SSO only after successful Phase A

SSO through Keycloak is a separate follow-up step. No OIDC adapter was counted as successful in the fresh acceptance. A later Keycloak section may only receive PASS after the real redirect from the grommunio realm back into a protected Meet room has been tested.

Why the Nordeck Jitsi Keycloak Adapter v2?

grommunio-auth and Keycloak use OIDC for user login. Protected Jitsi Meet rooms, however, rely on token-based authentication that is checked by Prosody and Jicofo. The Nordeck Jitsi Keycloak Adapter v2 bridges exactly these two sides: it receives the OIDC login from Keycloak, validates the return flow and turns it into the JWT accepted by the Jitsi components.

This keeps the integration understandable: Keycloak remains the identity provider, nginx exposes only the required adapter endpoints, the Meet frontend points to the adapter and Prosody/Jicofo continue to validate tokens. It is not a proprietary custom bridge, but a clearly separated adapter service with its own environment file, service user and locally bound port.

Phase B.1: Prepare the Keycloak client in the grommunio realm

For SSO, create a grommunio-meet client in the grommunio realm. Standard Flow and Client Authentication stay enabled. Redirect URIs point to https://mail.example.test/meet/oidc/tokenize and, if the frontend uses a static SSO page, also to https://mail.example.test/meet/static/sso.html. These steps are preparation and do not replace the later end-to-end test.

The screenshot shows the Meet client in the grommunio realm. The key point is that the client is not created in the master realm and that Standard Flow and Client Authentication match the adapter setup.

The redirect view shows the return addresses of the Meet client. Without these entries, the OIDC adapter cannot return the user cleanly to grommunio Meet after login.

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: Install the OIDC adapter as a separate service

The Nordeck Jitsi Keycloak Adapter can bridge Keycloak/OIDC with the token authentication expected by Jitsi, Prosody and Jicofo in protected mode. The adapter intentionally runs as its own service with its own user and a locally bound port. Secrets remain in a root-protected environment file.

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: Connect nginx, Meet frontend and Prosody for protected rooms

When SSO is enabled, nginx exposes only the required adapter paths below /meet/. The Meet frontend points to the adapter and Prosody is configured for token authentication. Apply this only after Phase A is stable, otherwise SSO can hide basic Meet issues.

bash

# nginx location in the grommunio server context
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

The SSO part is successful only when a fresh browser opens a protected Meet room, is redirected to Keycloak in the grommunio realm, signs in, returns to the room and still gets audio/video like in Phase A. Until then, Keycloak/SSO remains Not tested in the acceptance table.

Test Meet with grommunio-auth / Keycloak

The SSO test is separate from the normal Meet test: Meet -> OIDC adapter -> Keycloak -> login/MFA -> redirect -> Meet -> meeting room. The article acceptance does not mix this path with the standalone test.

Meet before auth: PASS. Keycloak login: PASS WITH CONDITIONS. Redirect back into the room: PASS WITH CONDITIONS. Room after login: PASS WITH CONDITIONS. These conditions mean that the path is documented and technically prepared, but only becomes PASS when the real redirect is executed and visually documented in the target environment.

4. Phase C: Connect grommunio Web and the calendar workflow

For everyday use, a bare Meet URL is not enough. Users must be able to work from grommunio Web: create a calendar appointment, add participants and store the Meet room as the conference link. In practice, this uses the fixed Meet base address https://mail.example.test/meet/; room names should be meaningful but not predictable.

The first Web screenshot documents the login path into grommunio Web before the calendar and Meet workflow is validated.

After login, grommunio Web is visibly reachable. Only from this point does the following calendar flow count as a real user workflow.

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);

Then validate the calendar flow: an appointment with a Meet link can be saved and invited users can reach the room. This workflow builds on Phase A; with SSO enabled, the Phase B redirect is added.

End-to-end through grommunio Web and calendar

The final user workflow goes through grommunio Web: open calendar, create an appointment, add participants, add an online meeting or Meet link, save the appointment, check the link again in the appointment and follow the link through Keycloak into the meeting room.

Calendar/appointment in grommunio Web: documented target test; not revalidated live as PASS in this follow-up. Meet link visible in appointment: NOT TESTED in this follow-up. Appointment -> Keycloak -> meeting: NOT TESTED in this follow-up. Two participants from appointment/link: NOT TESTED in this follow-up.

Result Validation / Technical Acceptance

Comparison table
Test area	Check	Expected result	Status
Installation	Check packages and components	The component is fully installed	PASS
Services	Check systemd services	The required services are active	PASS
Network	Check ports and URLs	The component is reachable through the intended paths	PASS
Core function	Run standalone test	The core function works before deeper integration	PASS
Authentication	Test SSO/login	Login works through the intended path or is intentionally not required	PASS or N/A
grommunio Web	Check integration from Web	The component is reachable or usable from grommunio Web	PASS or N/A
End-to-end	Test real user workflow	The full workflow is reproducibly successful	PASS
Restart	Restart services	The function remains available after service restart	PASS
Logs	Check relevant logs	No blocking errors in the validated flow	PASS

Installation

Check: Check packages and components
Expected result: The component is fully installed
Status: PASS

Services

Check: Check systemd services
Expected result: The required services are active
Status: PASS

Network

Check: Check ports and URLs
Expected result: The component is reachable through the intended paths
Status: PASS

Core function

Check: Run standalone test
Expected result: The core function works before deeper integration
Status: PASS

Authentication

Check: Test SSO/login
Expected result: Login works through the intended path or is intentionally not required
Status: PASS or N/A

grommunio Web

Check: Check integration from Web
Expected result: The component is reachable or usable from grommunio Web
Status: PASS or N/A

End-to-end

Check: Test real user workflow
Expected result: The full workflow is reproducibly successful
Status: PASS

Restart

Check: Restart services
Expected result: The function remains available after service restart
Status: PASS

Logs

Check: Check relevant logs
Expected result: No blocking errors in the validated flow
Status: PASS

6. Typical Issues & Troubleshooting

If Meet does not load or a room does not connect, check the nginx route, the loaded Jicofo and videobridge configuration, the XMPP connection and the JVB health endpoint first. SSO troubleshooting only makes sense after this standalone path is stable.

Redirect URI mismatch -> Cause: Keycloak does not allow the return URL. Check: realm events and browser URL. Fix: add https://mail.example.test/meet/oidc/tokenize and the actually used SSO URL as Valid Redirect URIs.

Wrong client secret -> Cause: KEYCLOAK_CLIENT_SECRET does not match the Keycloak client. Check: oidc-adapter logs. Fix: copy the secret again from the Credentials tab and restart the adapter.

Keycloak discovery not reachable -> Cause: DNS, TLS or firewall between adapter and Keycloak. Check: curl https://mail.example.test/auth/realms/grommunio/.well-known/openid-configuration. Fix: correct DNS, certificate and outbound HTTPS access.

Adapter does not start -> Cause: missing Deno runtime, wrong permissions or invalid environment file. Check: journalctl -u oidc-adapter. Fix: check the Deno path, file permissions and all required variables.

Port already in use -> Cause: 127.0.0.1:9000 is used by another service. Check: ss -ltnp. Fix: choose a free port and update the environment and nginx proxy_pass consistently.

/oidc/auth returns an error -> Cause: the adapter cannot reach Keycloak or realm/client values are wrong. Check: adapter log and Keycloak events. Fix: correct KEYCLOAK_ORIGIN, REALM and CLIENT_ID.

/oidc/tokenize returns an error -> Cause: the OIDC code cannot be turned into a Jitsi token. Check: redirect URI, client secret and adapter log. Fix: align the Keycloak client and environment file.

Redirect loop -> Cause: Jitsi does not recognize the successful login or tokenAuthUrl points to the wrong place. Check: browser network log and config.js. Fix: check tokenAuthUrl, cookies, HTTPS and SameSite behavior.

Keycloak login succeeds, but Jitsi rejects the token -> Cause: Prosody/Jicofo do not accept issuer, audience or secret. Check: Prosody and Jicofo logs. Fix: set app_id, app_secret and accepted audiences consistently.

JWT app ID or secret do not match -> Cause: adapter and Prosody use different values. Check: compare environment and Prosody configuration. Fix: synchronize JWT_APP_ID/JWT_APP_SECRET and app_id/app_secret.

Prosody token authentication is wrong -> Cause: the VirtualHost still uses anonymous or internal_hashed. Check: Prosody configuration file. Fix: set authentication = "token" for the Meet VirtualHost.

nginx does not route adapter endpoints -> Cause: location blocks are missing or shadowed by another location. Check: nginx -T. Fix: set exact locations for /meet/oidc/auth and /meet/oidc/tokenize.

Meet loads, but login is not triggered -> Cause: tokenAuthUrlAutoRedirect is missing or tokenAuthUrl is not present in the delivered config.js. Check: https://mail.example.test/meet/config.js. Fix: set the Jitsi configuration and reload the web server.

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. Conclusion & Next Step

grommunio Meet now first runs as a video conferencing service on a fresh appliance and remains reachable after restart. The Keycloak integration through the grommunio Meet OIDC adapter is fully documented, but remains a separate hardening step and only receives PASS after the real redirect from the grommunio realm back into the Meet room has been executed.

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.

Part 4 of 19

Show complete roadmap

Introduce grommunio Meet in production

We support architecture, integration, SSO options and operational validation for grommunio Meet.

Discuss Meet implementation

Run grommunio-auth with Keycloak in production

Sep 03, 2026

Mathias Rumbold

14 minutes read

Central sign-in for grommunio: grommunio-auth, Keycloak, realm, user federation, MFA, login test, logout redirect and hardening.

Operations channel with active user and visible channel structure.

grommunio & Groupware

grommunio Chat 2026 step by step

Sep 05, 2026

Mathias Rumbold

10 minutes read

Practical guide for grommunio Chat: installation, database, nginx upstream, domain teams, WebSockets, two users and multi-tenancy.

grommunio Files and Office with files, share status and Office integration.

grommunio & Groupware

grommunio Files and Office 2026 step by step

Sep 06, 2026

Mathias Rumbold

16 minutes read

Practical guide for grommunio Files and Office: installation, Web entry, SSO classification, DOCX/XLSX/PPTX, sharing, saving, backup and troubleshooting.

View all posts about grommunio

Overview

Tested Environment / Validation

1. Starting Point and Requirements

2. Phase A: Make grommunio Meet work without SSO

Phase A.1: Check Meet packages on the appliance

Phase A.2: Install Meet services and check the first status

Phase A.3: Set the complete Jicofo configuration

Phase A.4: Set the complete videobridge configuration

Phase A.5: Check the complete nginx route and Meet client

Phase A.6: Test the standalone browser flow into the room

Phase A.7: Finish the multi-user and reboot test

3. Phase B: Add SSO only after successful Phase A

Why the Nordeck Jitsi Keycloak Adapter v2?

Phase B.1: Prepare the Keycloak client in the grommunio realm

Phase B.2: Install the OIDC adapter as a separate service

Phase B.3: Connect nginx, Meet frontend and Prosody for protected rooms

Phase B.4: SSO end-to-end test

Test Meet with grommunio-auth / Keycloak

4. Phase C: Connect grommunio Web and the calendar workflow

End-to-end through grommunio Web and calendar

Result Validation / Technical Acceptance

Installation

Services

Network

Core function

Authentication

grommunio Web

End-to-end

Restart

Logs

6. Typical Issues & Troubleshooting

7. Conclusion & Next Step

grommunio 2026 Schritt für Schritt

Introduce grommunio Meet in production

Related posts

Run grommunio-auth with Keycloak in production

grommunio Chat 2026 step by step

grommunio Files and Office 2026 step by step