Sta geautoriseerde gebruikers toe om Jitsi-rooms aan te maken met Keycloak-aanmelding.

Om het aanmaken van Jitsi Meet-ruimtes te beperken tot specifieke personen, vereis je geauthenticeerde hosts en geef je alleen inloggegevens uit aan goedgekeurde accounts. Voor nieuwe zelfgehoste installaties raadt Jitsi nu authenticatie op basis van tokens aan; deze handleiding gebruikt Keycloak als identiteitsprovider en staat uitgenodigde gasten alleen toe om deel te nemen aan ruimtes nadat een goedgekeurde host deze heeft aangemaakt.

1. Controleer de implementatie en kies uw hostaccounts.

Deze instructies zijn bedoeld voor een zelfgehoste Jitsi Meet-installatie vanuit Debian- of Ubuntu-pakketten, met beheerdersrechten voor Prosody, Nginx en de Jitsi-webconfiguratie. Er wordt vanuit gegaan dat Keycloak al is geïnstalleerd of veilig kan worden geïmplementeerd. Prosody is de XMPP-berichtenserver; een JSON Web Token (JWT) is een ondertekende authenticatiecode die wordt gebruikt om aan te tonen dat iemand is geauthenticeerd. Keycloak is een identiteitsprovider die de gebruikersaanmelding afhandelt.

In de Jitsi-handleiding wordt het oudere recept voor Secure Domain met gebruikersnaam en wachtwoord als verouderd gemarkeerd en wordt bij nieuwe installaties verwezen naar tokenauthenticatie. De huidige authenticatie-instructies zijn bijgewerkt op 5 oktober 2026. Als u al Docker gebruikt, kopieer dan de onderstaande pakketpaden niet: de officiële Docker-configuratiehandleiding gebruikt omgevingsvariabelen zoals ENABLE_AUTH, ENABLE_GUESTS, en AUTH_TYPE.

Voordat u wijzigingen aanbrengt, noteer de hostnaam van uw openbare vergadering, controleer of HTTPS werkt, maak een back-up van de configuratiebestanden die u wilt wijzigen en bepaal welke accounts met een naam vergaderingen mogen hosten. In dit voorbeeld is het vergaderingsadres jitsi.example.com; vervang dit overal door uw daadwerkelijke hostnaam.

2. Geef alleen goedgekeurde hosts toegang in Keycloak.

Maak een aparte server aan.

Maak in de Keycloak-beheerconsole een realm aan en selecteer deze met de naam jitsi-realm. Een realm is een geïsoleerde verzameling gebruikers en applicatie-instellingen. Schakel open gebruikersregistratie uit en voorkom het automatisch importeren van een onbeperkte bedrijfsdirectory: met deze configuratie kan elk account dat zich kan authenticeren bij de geaccepteerde realm een ​​vergadering aanmaken.

Registreer de Jitsi-webclient

Maak een OpenID Connect-client aan met de naam jitsi. OpenID Connect (OIDC) is het aanmeldingsprotocol dat Keycloak gebruikt om identiteitsgegevens naar Jitsi te verzenden. Volg het officiële Jitsi-voorbeeld en voer exact dezelfde callback-waarden in, waarbij u de hostnaam aanpast:

• Geldige omleidings-URI:https://jitsi.example.com/static/sso.html
• Geldige omleidings-URI na uitloggen:https://jitsi.example.com/static/logout.html
• Herkomst van de website:https://jitsi.example.com

Voeg de toegestane personen toe.

Maak onder Gebruikers een account aan voor elke geautoriseerde host en stel vervolgens het wachtwoord van die gebruiker in onder Referenties. Gebruik aparte accounts in plaats van één beheerdersaccount te delen. Een account dat geen vergaderingen meer mag aanmaken, moet worden uitgeschakeld of de toegang tot dit domein moet op een andere manier worden geweigerd. Als u beperkingen nodig hebt voor slechts één groep binnen een gedeeld domein, voeg dan een afzonderlijk geverifieerd autorisatiebeleid toe; de ​​stappen hier dwingen Keycloak-groepslidmaatschap niet automatisch af.

3. Verbind Keycloak met de Jitsi-server.

Proxy Keycloak-realm-eindpunten via HTTPS

Configureer Keycloak met de juiste openbare hostnaam en vertrouwde reverse-proxy-headers, en routeer vervolgens /realms/verzoeken van uw Jitsi-hostnaam naar de privé Keycloak-listener. Voor een Keycloak-instantie die beschikbaar is op 127.0.0.1:18080, voegt u het volgende locatieblok toe binnen het bestaande Jitsi Nginx HTTPS-serverblok, vóór de algemene Jitsi-routes:

location ~ ^/realms/(.*) {
    proxy_pass http://127.0.0.1:18080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Dit gaat ervan uit dat Keycloak lokaal bereikbaar is op die poort; vervang de upstream-poort door die van uw implementatie. Stel de beheerdersconsole of backend-poort van Keycloak niet onnodig open. Raadpleeg de documentatie van Keycloak over reverse-proxy's voor informatie over proxy- en hostnaaminstellingen in productieomgevingen.

Vereist tokens in Prosody

Bewerk de /etc/prosody/conf.avail/jitsi.example.com.cfg.luainstellingen. Voeg de instellingen voor de uitgever en het publiek toe en werk vervolgens het bestaande hoofdbestand bij VirtualHostom tokenauthenticatie te gebruiken. Voeg deze regels samen met de andere instellingen; maak geen tweede kopie van dat hostblok aan.

asap_accepted_issuers = { "https://jitsi.example.com/realms/jitsi-realm" }
asap_accepted_audiences = { "account" }
asap_require_room_claim = false

VirtualHost "jitsi.example.com"
    authentication = "token"
    app_id = "jitsi"
    allow_empty_token = false
    cache_keys_url = "https://jitsi.example.com/realms/jitsi-realm/protocol/openid-connect/certs"

Voor gasttoegang voegt u een aparte guest.jitsi.example.comvirtuele host toe met authentication = "jitsi-anonymous", c2s_require_encryption = false, en de smacksmodule, zoals weergegeven in de Jitsi-instructies. Dit is een intern XMPP-domein: maak hiervoor geen openbare DNS of een apart certificaat aan. Voeg in de modulelijst van de bestaande hoofdhost toe ; voeg in de modulelijst van persistent_lobbyde bestaande MUC-component toe . Een MUC is de component voor chatten met meerdere gebruikers die vergaderruimtes beheert. Behoud de modules die al in de lijst staan.conference.jitsi.example.commuc_wait_for_host

Configureer de aanmeldingsprocedure via de browser

/etc/jitsi/meet/jitsi.example.com-config.jsVoeg in anonymousdomain: 'guest.jitsi.example.com'het bestaande hostsobject de volgende instellingen toe:

config.tokenAuthUrl='https://'+ config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect/auth?client_id=jitsi&response_type=code&scope=openid&state={state}&redirect_uri=https://'+ config.hosts.domain + '/static/sso.html&code_challenge={code_challenge}&code_challenge_method=S256';
config.tokenLogoutUrl='https://'+ config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect/logout?post_logout_redirect_uri=https://'+ config.hosts.domain + '/static/logout.html';
config.tokenAuthInline=true;
config.sso={ ssoService: config.hosts.domain, tokenService: config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect', clientId: "jitsi" };

Deze waarden implementeren de autorisatiecode-aanmeldingsprocedure met PKCE (Proof Key for Code Exchange), een beveiliging voor browsergebaseerde autorisatie. In de Jitsi-handleiding staat specifiek vermeld dat jicofo.confauthenticatie uitgeschakeld moet blijven voor de tokenmodus; kopieer het verouderde XMPP Secure Domain-authenticatieblok niet.

Valideer en herlaad de services.

Controleer de Nginx-syntaxis en herstart vervolgens alleen de services die worden vermeld in de huidige instructies voor tokenauthenticatie. Voer deze wijzigingen uit tijdens een onderhoudsvenster als uw Jitsi-server al in gebruik is.

sudo nginx -t
sudo systemctl restart prosody
sudo systemctl restart nginx

4. Vermijd deze fouten bij het verlenen van toestemming en inloggen.

• Iedereen kan nog steeds een kamer starten: controleer of de hoofd-Prosody-host is geverifieerd met een token, lege tokens zijn niet toegestaan ​​en de gasthost is een aparte host. Test dit in een schone browsersessie, niet in een sessie waarin nog een geldige aanmelding actief is.
• Goedgekeurde gebruikers kunnen niet inloggen: vergelijk de Keycloak realm issuer, de openbare HTTPS-hostnaam, de client-ID, de redirect-URI en de Prosody cache_keys_url. Een mislukte browserredirect is geen bewijs dat de gebruikersrechten correct zijn.
• Gasten betreden nooit een kamer: controleer het anonieme domein in zowel Prosody als Jitsi config.js, plus de wachtmodules voor de host. Een lobby- of gastwachtstatus is iets anders dan een authenticatiefout.

5. Controleer wie een nieuwe vergadering kan aanmaken.

Open een URL van een vergaderruimte die nog nooit eerder is gebruikt in een privévenster van je browser, zonder in te loggen. De gast zou de conferentie niet als eerste host moeten kunnen starten. Log vervolgens in als een geautoriseerde Keycloak-gebruiker en maak die vergaderruimte aan; een uitgenodigde gast zou dan moeten kunnen deelnemen als je het gastdomein hebt ingeschakeld. Probeer ten slotte een uitgeschakeld of niet-geautoriseerd account en controleer of dit account zich niet kan authenticeren en een nieuwe vergaderruimte kan aanmaken.

Als een test mislukt, controleer sudo journalctl -u prosody -u nginx --since "10 minutes ago"dan de Keycloak-authenticatiegebeurtenissen, zonder tokens of wachtwoorden uit de logboeken te publiceren. De oplossing is pas bevestigd als een geautoriseerd account een nieuwe kamer kan aanmaken en een niet-geauthenticeerde gebruiker dat niet kan.