承認されたユーザーがKeycloakサインインを使用してJitsiルームを作成できるようにする

Jitsi Meetのルーム作成を特定のユーザーに限定するには、認証済みのホストを必須とし、承認されたアカウントにのみ認証情報を発行します。新規のセルフホスト型インストールの場合、Jitsiはトークンベースの認証を推奨しています。このガイドでは、KeycloakをIDプロバイダーとして使用し、招待されたゲストは承認されたホストがルームを開始した後にのみ参加できるようにします。

1. デプロイメントを確認し、ホストアカウントを選択します。

これらの手順は、DebianまたはUbuntuパッケージからインストールされた、Prosody、Nginx、およびJitsi Web設定への管理者権限を持つ、自己ホスト型のJitsi Meetインストール環境を対象としています。Keycloakは既にインストールされているか、安全にデプロイできることを前提としています。ProsodyはXMPPメッセージングサーバーであり、JSON Webトークン（JWT）は認証済みであることを証明するために使用される署名付き認証情報です。Keycloakは、ユーザーサインインを処理するIDプロバイダーです。

Jitsi ハンドブックでは、古いユーザー名とパスワードによるセキュア ドメインの手順は非推奨となり、新規インストールではトークン認証を使用するように指示されています。現在の認証手順は2026 年 10 月 5 日に更新されました。すでに Docker を使用している場合は、以下のパッケージ パスをコピーしないでください。公式のDocker 構成ガイドではENABLE_AUTH、、、ENABLE_GUESTSなどの環境変数を使用していますAUTH_TYPE。

編集する前に、公開ミーティングのホスト名をメモし、HTTPSが正しく動作することを確認し、変更予定の設定ファイルをバックアップし、どの名前付きアカウントがミーティングをホストできるかを決定してください。この例では、ミーティングアドレスは です。jitsi.example.com実際のホスト名に置き換えてください。

2. Keycloakで承認されたホストのみにアクセスを許可する

専用領域を作成する

Keycloak 管理コンソールで、という名前のレルムを作成して選択しますjitsi-realm。レルムは、ユーザーとアプリケーション設定の隔離された集合です。オープンなユーザー登録を無効にし、制限のない会社ディレクトリの自動インポートを回避します。この構成では、承認されたレルムに対して認証できるアカウントはすべて、会議の作成者になる可能性があります。

Jitsiウェブクライアントを登録する

という名前の OpenID Connect クライアントを作成しますjitsi。OpenID Connect (OIDC) は、Keycloak が Jitsi に ID 情報を返すために使用するサインイン プロトコルです。公式の Jitsi の例に従って、ホスト名を調整して、以下のコールバック値を正確に入力します。

• 有効なリダイレクトURI：https://jitsi.example.com/static/sso.html
• 有効なログアウト後のリダイレクトURI：https://jitsi.example.com/static/logout.html
• ウェブオリジン：https://jitsi.example.com

許可された人を追加する

「ユーザー」セクションで、承認済みホストごとにアカウントを作成し、「認証情報」セクションでそのユーザーのパスワードを設定します。管理者ログインを1つ共有するのではなく、個別のアカウントを使用してください。会議を作成しないようにするアカウントは、無効化するか、このレルムへの認証を拒否する必要があります。共有レルム内の1つのグループのみに制限が必要な場合は、別途検証済みの認証ポリシーを追加してください。ここでの手順では、Keycloakグループメンバーシップは自動的に適用されません。

3. KeycloakをJitsiサーバーに接続する

KeycloakレルムエンドポイントをHTTPS経由でプロキシする

Keycloak を正しいパブリックホスト名と信頼できるリバースプロキシヘッダーで設定し、/realms/Jitsi ホスト名からのリクエストをそのプライベート Keycloak リスナーにルーティングします。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のリバースプロキシに関するドキュメントを参照してください。

Prosodyでトークンを要求する

編集します/etc/prosody/conf.avail/jitsi.example.com.cfg.lua。発行者とオーディエンスの設定を追加し、既存のメイン設定を更新してVirtualHostトークン認証を使用するようにします。これらの行を他の設定とマージします。ホストブロックの2つ目のコピーを作成しないでください。

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仮想ホストを追加します。これは内部 XMPP ドメインです。パブリック DNS や個別の証明書は作成しないでください。既存のメイン ホストのモジュール リストに を追加し、既存のMUC コンポーネント モジュール リストに を追加します。MUC は、会議室を管理するマルチ ユーザー チャット コンポーネントです。既にリストされているモジュールはそのままにしておきます。authentication = "jitsi-anonymous"c2s_require_encryption = falsesmackspersistent_lobbyconference.jitsi.example.commuc_wait_for_host

ブラウザのサインインフローを設定する

では/etc/jitsi/meet/jitsi.example.com-config.js、anonymousdomain: 'guest.jitsi.example.com'既存のhostsオブジェクトに追加します。Jitsi で文書化されている OIDC 設定を追加します。

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（Proof Key for Code Exchange）を使用した認証コードサインインフローを実装します。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とwait-for-hostモジュールを確認してください。ロビーやゲストの待機状態は、認証失敗とは異なります。

5. 新しい会議を作成できるユーザーを確認する

未使用のルームURLを、サインインせずにプライベートブラウジングウィンドウで開きます。ゲストは最初のホストとして会議を開始できないはずです。次に、承認済みのKeycloakユーザーとしてサインインし、そのルームを作成します。ゲストドメインを有効にしていれば、招待したゲストが参加できるようになります。最後に、無効化されたアカウントまたは未承認のアカウントを試して、認証できず、新しいルームを作成できないことを確認します。

いずれかのテストが失敗した場合は、sudo journalctl -u prosody -u nginx --since "10 minutes ago"ログからトークンやパスワードを公開せずに、Keycloak認証イベントと併せて検査してください。修正が正しく行われたかどうかは、承認されたアカウントが新しいルームを作成でき、認証されていないユーザーが作成できない場合にのみ確認できます。