Jitsi Meetで認証とパスワード保護を有効にする方法

Jitsi Meetには2つの独立した保護制御があります。サーバー認証はミーティングを作成できるユーザーを決定し、ルームパスワードはパスワードを知らないユーザーがルームに参加できないようにします。これらは異なる問題を解決します。セルフホスト型サーバーでは、以前のProsody「セキュアドメイン」設定では、ルームの作成にユーザー名とパスワードを要求しつつ、ゲストの参加を許可できます。Jitsiの最新のハンドブックでは、この方法は新規インストールでは非推奨となり、代わりにトークンベースの認証が推奨されています。既存の管理者は、以下の手順を互換性ガイドとして使用できますが、新しい展開はサポートされているトークンまたはIDプロバイダーの設定に基づいて計画する必要があります。

ルームパスワードは、会議中の独立した機能であり、サーバー認証と併用することで役立ちます。ルーム開始後にパスワードを設定し、プライベートチャネルで共有し、参加者を招待する前に別のブラウザから参加フローをテストしてください。

どのような保護が必要ですか？

小規模な会議であれば、固有の会議室名と会議室パスワードだけで十分な場合もあります。アカウントベースの会議室作成が必要な組織の場合は、サーバー認証も設定してください。新規にセルフホスト型で導入する場合は、実装方法を選択する前に、Jitsiの最新の認証ガイドと関連するトークン認証の設定を確認してください。

Jitsiのルームをパスワードで保護するにはどうすればよいですか？

会議を開始し、ツールバーのセキュリティまたは会議オプションメニューを開き、パスワード操作を選択して、強力なルームパスワードを入力します。メニューのラベルとアイコンは、クライアントのバージョンによって異なる場合があります。会議が既に開始されている場合、パスワードを設定すると今後の参加者に影響します。既に参加している参加者は自動的に退出しません。機密性が重要な場合は、会議リンクとは別にパスワードを送信してください。

JitsiのFAQによると、会議室のパスワードは会議終了時に削除されるため、定期的な会議でもパスワードが保持されるとは限りません。新しい会議ごとにパスワードを再度設定し、ご自身の環境で動作を確認してください。パスワードを受け取ったり転送されたりした人は誰でも入室できる可能性があるため、パスワードは指定ユーザーアクセスリストとは異なります。会議の保護については、Jitsiの公式FAQをご覧ください。

サーバー認証によって何が変わるのか？

従来の「セキュアドメイン」設計では、Prosodyはローカルアカウントに対してルーム作成者の認証を行います。その後、Jitsiは認証されていない参加者がゲストドメイン経由で接続できるようにします。これは、スタッフのみがルームを開始し、参加者はアカウントを必要としない場合に便利です。すべての参加者がサインインする必要はありません。すべてのユーザーが認証する必要がある場合は、ゲストアクセスを無効にするか、現在の認証設計で使用されているIDおよびアクセスポリシーに置き換える必要があります。

Jitsiのドキュメントでは、この古いセキュアドメイン方式は新規インストールでは非推奨とされています。この制限を理解し、互換性のある既存のサーバーを維持している場合にのみ、この方法を継続してください。編集を行う前に、Jitsiのインストール方法を確認し、Jitsi Meetのホスト名をメモし、Prosody、Jicofo、およびWeb構成ファイルをバックアップし、構文エラーによってサービスが中断された場合に備えて、アクティブな管理者セッションまたはコンソールを利用できる状態にしておいてください。

DebianまたはUbuntuパッケージのインストール時に、従来のセキュアドメイン設定を有効にするにはどうすればよいですか？

1. Prosodyの仮想ホストを変更する

Jitsiホスト名のProsodyファイルを開きます（通常は/etc/prosody/conf.avail/jitsi.example.com.cfg.lua）。以下のサンプルホスト名を実際のドメイン名に置き換えてください。メインの仮想ホストで、認証モードをハッシュ化された内部パスワードに変更します。その後にゲスト仮想ホストを追加します。

VirtualHost "jitsi.example.com"
    authentication = "internal_hashed"

VirtualHost "guest.jitsi.example.com"
    authentication = "jitsi-anonymous"
    c2s_require_encryption = false

既存のオプションとモジュールはそのまま維持します。DNS レコードや公開証明書は作成しないでくださいguest.jitsi.example.com。この構成では、これは Jitsi の内部ドメインです。

2. ゲストドメインについてWebクライアントに伝える

既存のオブジェクトを開いて/etc/jitsi/meet/jitsi.example.com-config.js、その中に追加します。既存のエントリやその他のエントリはそのまま残し、カンマを注意深く確認してください。anonymousdomainhostsdomain

hosts: {
    domain: 'jitsi.example.com',
    anonymousdomain: 'guest.jitsi.example.com'
},

3. Jicofoで認証を有効にする

編集します/etc/jitsi/jicofo/jicofo.conf。認証設定を既存のjicofoブロック内に追加します。重複するトップレベルブロックは作成しないでください。

jicofo {
  authentication {
    enabled = true
    type = XMPP
    login-url = "jitsi.example.com"
  }
}

ファイルに既にjicofoセクションが存在する場合は、これらのプロパティをそのセクションにマージしてください。設定構文と生成されるファイルはパッケージのバージョンによって異なる場合があるため、サービスを再起動する前に、結果をご使用の環境のハンドブックページと比較してください。

4. サービスを再起動し、アカウントを作成します。

編集内容を確認後、管理者としてサービスを再起動してください。

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jitsi-videobridge2

Prosodyでルーム作成者アカウントを登録してください。プレースホルダーを置き換えてください。本番サーバーでは、サンプルドメインや脆弱なパスワードは絶対に使用しないでください。

sudo prosodyctl register <username> jitsi.example.com <strong-password>

各アカウントはJitsiホスト名に関連付けられています。後でアクセス権を取り消す必要がある場合は、管理者認証情報を共有するのではなく、個別のアカウントを作成してください。Jitsiのセキュアドメインに関するドキュメントには、パッケージ固有の設定パスと登録コマンドが記載されています。また、この方法は非推奨であると明記されています。

Dockerでは、設定はどのように異なりますか？

実行中のコンテナ内のファイルを編集したり、DebianパッケージのパスをDockerデプロイメントにコピーしたりしないでください。公式のDocker Compose設定では、認証はデプロイメントの環境ファイルを通じて構成されます。ハンドブックには、内部アカウント認証に関する以下の関連値が記載されています。

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

参加者が自身のアカウントを持たずに参加できるようにするには、ゲストアクセスを有効にしたままにしてください。ゲストが有効になっている場合、認証されていないユーザーは設定されたゲスト動作に従って参加できますが、認証済みのルーム作成者になることはありません。デプロイメントには Compose ワークフローを使用して環境変更を適用し、サービスが正常に起動しない場合はログを確認してください。

生成されたコンテナ構成を変更するのではなく、Prosody サービスを通じて内部ユーザーを作成してください。公式ハンドブックでは、Prosody コンテナ内でシェルを開き、ユーザーを登録する方法が示されていますprosodyctl。構成パスと XMPP ドメインは Compose のリリースによって異なります。ドキュメントに記載されている Docker イメージでは、Prosody 構成は の下にあり/config/prosody.cfg.lua、例の XMPP ドメインは です。チェックアウトしたリリースについて記載されている正確なコマンドと値を使用してください。環境変数、アカウントの作成、および生成された構成の動作については、meet.jitsi公式のDocker セルフホスティングガイドを参照してください。

保護機能が動作していることをどのように確認できますか？

• プライベートブラウザウィンドウを開き、新しいルームを作成してみてください。通常のセットアップでは、アカウント認証情報の入力を求められるはずです。
• 新しいアカウントでサインインし、ルームを作成してください。ミーティングが読み込まれ、ホストが期待どおりのモデレーター権限を持っていることを確認してください。
• 別のブラウザからゲストとして参加してください。ゲスト参加が有効になっている場合、作成者アカウントがなくても参加できます。追加の入場確認が必要な場合は、ルームのパスワードまたはロビーを追加してください。
• ルームにパスワードを設定し、パスワードなしとパスワードありの両方で、新しいプライベートウィンドウから参加を試みてください。パスワードを設定した場合でも、既にルーム内にいる参加者が接続を維持していることを確認してください。
• テストミーティング終了後、新しいルームを開始し、JitsiのFAQに記載されている手順に従って、パスワードを再設定する必要があるかどうかを確認してください。

サインインプロンプトが表示されない場合は、Prosody ホスト名、Jicofo ブロック、クライアントanonymousdomain値、およびサービスログを確認してください。よくある設定エラーとしては、Prosody と の間で一致しないゲストドメインを使用していることconfig.js、または既存のブロックを拡張する代わりに 2 番目の Jicofo ブロックを追加していることが挙げられます。ゲストが参加できない場合は、ゲストアクセスが意図的に有効になっていること、および設定されているゲストドメインがメインホスト名と一致していることを確認してください。

新規設置の場合、何を選ぶべきでしょうか？

互換性に関する特別な理由がない限り、非推奨のセキュアドメインレシピを使用して新規展開を開始しないでください。Jitsiの現在のセルフホスティング資料では、新規インストールにはトークン認証を推奨していますが、より包括的な認証ガイドでは、新しいIDプロバイダーとの統合について説明しています。これらのアプローチでは、発行者、署名、またはIDプロバイダーの追加設定が必要となり、Prosodyルームパスワードとは互換性がありません。要件に合ったモデルを選択し、必要に応じてルームパスワードまたはロビーを個別の会議レベルの制御として使用してください。

要するに、アカウント認証またはトークン認証を使用してルームを作成できるユーザーを制御し、ルームパスワードを設定して、後から参加できるユーザーを秘密のパスワードを知っているユーザーのみに制限します。どちらか一方を有効にしてももう一方が自動的に有効になるわけではないため、両方の方法を個別にテストしてください。

公式資料

• Jitsi Meet: 認証
• Jitsi Meet: セキュアなドメイン設定（非推奨）
• Jitsi Meet: トークン認証
• Jitsi Meet：Dockerセルフホスティングガイド
• Jitsi Meet：よくある質問と会議の保護