允許已批准的使用者使用 Keycloak 登入建立 Jitsi 會議室

為了限制只有特定人員才能建立 Jitsi Meet 會議室，請要求主持人必須經過身份驗證，並且僅向已批准的帳戶發放憑證。對於新的自架安裝，Jitsi 現在建議使用基於令牌的身份驗證；本指南使用 Keycloak 作為身份提供程序，並允許受邀嘉賓僅在已批准的主持人創建會議室後才能加入。

1. 檢查部署情況並選擇您的主機帳戶

本指南針對使用 Debian 或 Ubuntu 軟體包自行部署的 Jitsi Meet，並要求使用者擁有對 Prosody、Nginx 和 Jitsi Web 配置的管理員權限。指南假設 Keycloak 已安裝或可安全部署。 Prosody 是 XMPP 訊息伺服器；JSON Web Token (JWT) 是一種簽章憑證，用於證明使用者已通過身份驗證。 Keycloak 是一個身分識別提供程序，用於處理使用者登入。

Jitsi 手冊已將舊的使用者名稱和密碼安全性網域設定方法標記為已棄用，並建議新安裝的使用者使用令牌認證。其目前的認證說明已於 2026 年 10 月 5 日更新。如果您已在使用 Docker，請勿複製以下軟體包路徑：官方Docker 配置指南ENABLE_AUTH使用諸如` docker-compose up`、 ENABLE_GUESTS`docker-compose up` 和`docker-compose up`之類的環境變數AUTH_TYPE。

在編輯之前，請記下您的公開會議主機名，確認 HTTPS 連線正常，備份您計劃修改的設定文件，並確定哪些指定帳戶可以主持會議。在本例中，會議地址為 [此處填寫會議地址] jitsi.example.com；請將其替換為您實際的會議主機名稱。

2. 僅向 Keycloak 中已核准的主機授予存取權限

創建一個專用領域

在 Keycloak 管理控制台中，建立並選擇一個名為 `<realm_name>` 的網域jitsi-realm。網域是使用者和應用程式設定的獨立集合。停用開放使用者註冊，並避免自動匯入不受限制的公司目錄：在此配置下，任何能夠透過身分驗證存取已接受網域的帳戶都可以成為會議建立者。

註冊 Jitsi Web 用戶端

建立一個名為 `<client_name>` 的 OpenID Connect 用戶端jitsi。 OpenID Connect (OIDC) 是 Keycloak 用於向 Jitsi 傳回身分識別資訊的登入協定。請依照 Jitsi 官方範例，輸入以下回呼值，並調整主機名稱：

• 有效的重定向 URI：https://jitsi.example.com/static/sso.html
• 有效的登出後重定向 URI：https://jitsi.example.com/static/logout.html
• 網址原文：https://jitsi.example.com

新增獲準人員

在「使用者」下，為每個授權主機建立一個帳戶，然後在「憑證」下設定該使用者的密碼。請使用單獨的帳戶，而不是共用一個管理員登入。不再需要建立會議的帳戶必須被停用，或被拒絕存取此網域。如果您只需要對共用網域中的一個群組進行限制，請新增一個單獨驗證的授權策略；此處的步驟不會自動強制執行 Keycloak 群組成員關係。

3. 將 Keycloak 連接到 Jitsi 伺服器

透過 HTTPS 代理 Keycloak 領域端點

使用正確的公用主機名稱和受信任的反向代理程式標頭來設定 Keycloak，然後將/realms/來自 Jitsi 主機名稱的請求路由到其私人 Keycloak 監聽器。對於位於 `<Jitsi 主機名稱>` 的 Keycloak 實例127.0.0.1:18080，請在現有的 Jitsi Nginx HTTPS 伺服器設定區塊中，在通用 Jitsi 路由之前，新增下列 location 設定區塊：

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

這假設 Keycloak 可以透過該連接埠在本地存取；請根據您的部署情況替換上游連接埠。請勿不必要地揭露 Keycloak 的管理控制台或後端連接埠。有關生產環境代理程式和主機名稱控制，請參閱Keycloak 的反向代理文件。

韻律學中需要標記

編輯/etc/prosody/conf.avail/jitsi.example.com.cfg.lua。新增發行者和受眾設置，然後更新現有主配置VirtualHost以使用令牌認證。將這些行與其其他設定合併－不要建立該主機區塊的第二個副本：

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"

若要實現訪客訪問，請按照 Jitsi 說明，新增一個單獨的guest.jitsi.example.com虛擬主機，並配置 `<host>` authentication = "jitsi-anonymous"、 `<module> c2s_require_encryption = false` 和 ` <module>` 模組。這是一個內部 XMPP 網域：請勿為其建立公共 DNS 或單獨的憑證。在現有主主機的模組清單中，加入 `<module> `；在現有MUC 元件的模組清單中，加入 ` <module>`。 MUC 是用於維護會議室的多用戶聊天元件。請保留已列出的模組。smackspersistent_lobbyconference.jitsi.example.commuc_wait_for_host

配置瀏覽器登入流程

在現有物件中新增以下內容。/etc/jitsi/meet/jitsi.example.com-config.js追加Jitsi 文件中記錄的 OIDC 設定：anonymousdomain: 'guest.jitsi.example.com'hosts

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" };

這些值實作了基於 PKCE（程式碼交換證明金鑰）的授權碼登入流程，PKCE 是一種用於保護基於瀏覽器的授權機制。 Jitsi 手冊明確指出，jicofo.conf在令牌模式下應停用身份驗證；請勿複製其已棄用的 XMPP 安全域驗證碼區塊。

驗證並重新載入服務

檢查 Nginx 語法，然後僅重新啟動目前令牌認證說明中列出的服務。如果您的 Jitsi 伺服器正在使用中，請在維護視窗期間執行這些變更：

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

4. 避免這些權限和登入錯誤

• 所有人仍然可以創建房間：請確認主 Prosody 主持人已通過令牌認證，不允許使用空令牌，並且訪客主持人必須單獨設置。請在乾淨的瀏覽器會話中進行測試，不要在仍有有效登入資訊的會話中進行測試。
• 已獲授權的使用者無法登入：請比較 Keycloak 網域頒發者、公用 HTTPS 主機名稱、用戶端 ID、重新導向 URI 和 Prosody cache_keys_url。瀏覽器重定向失敗並不能證明使用者權限正確。
• 訪客從未進入過房間：請檢查 Prosody 和 Jitsi 中的匿名域config.js，以及等待主機模組。大廳或訪客等待狀態與身分驗證失敗不同。

5. 確認誰可以建立新會議

在不登入的情況下，使用隱私瀏覽視窗開啟一個從未使用過的會議室 URL。訪客應該無法以首位主持人的身份發起會議。接下來，使用已核准的 Keycloak 使用者身分登入並建立該會議室；如果您已啟用訪客網域，受邀訪客應該可以加入會議。最後，嘗試使用一個已停用或未經批准的帳戶，並確認該帳戶無法通過身份驗證並建立新會議室。

如果任何測試失敗，sudo journalctl -u prosody -u nginx --since "10 minutes ago"請結合 Keycloak 驗證事件進行檢查，但不要從日誌中發布令牌或密碼。只有當已批准的帳戶可以建立新房間而未經身份驗證的使用者無法建立新房間時，才能確認修復成功。