Web会議システムのJitsiにユーザー認証を追加する
みなさんこんにちは
本日のお題
AWS上に展開しているWeb会議システムのJitsiに、ユーザー認証を追加して、ID/PASSを知っている人だけが利用できるように設定したい。(お友達内とか、企業内のみ等、利用者限定をしたい。)
そうしないと、ミサカが10000万人で利用する、無料のWeb会議システムになってしまって、AWSの利用料で朝起きたら破産する可能性があるためです。
開始前に
以前作成したJitsiのEC2を作業前に起動して、接続確認を行ってみましたが、つながりません。
確認したところ、EC2の「パブリック IPv4 アドレス オープンアドレス」(EC2に付与されたグローバルIP)が、変更されていました。
自動更新まで3日程度。ちょっと想定外の速さです。
AWSのEIP利用を検討する必要があるかもしれません。(月1000円くらい)
もっとも、、、実験なので、今のところ不要の認識です。
.env設定ファイルの設定
docker-composeで利用する.envファイルを設定します。
# Enable authentication
#ENABLE_AUTH=1
+ENABLE_AUTH=1
設定反映のために、Docker再起動を行います。
[root@meet docker-jitsi-meet]# docker-compose stop
[+] Running 4/4
⠿ Container docker-jitsi-meet-web-1 Stopped 3.7s
⠿ Container docker-jitsi-meet-jicofo-1 Stopped 3.9s
⠿ Container docker-jitsi-meet-jvb-1 Stopped 4.0s
⠿ Container docker-jitsi-meet-prosody-1 Stopped 3.6s
[root@meet docker-jitsi-meet]# docker-compose up -d
[+] Running 4/4
⠿ Container docker-jitsi-meet-prosody-1 Started 1.5s
⠿ Container docker-jitsi-meet-web-1 Started 1.5s
⠿ Container docker-jitsi-meet-jicofo-1 Started 3.5s
⠿ Container docker-jitsi-meet-jvb-1 Started 3.6s
[root@meet docker-jitsi-meet]#
接続テスト
接続したタイミングで、認証用のポップアップが出ましたが、ID/PASSがないことに気が付きました。
しかし、一応は成功しています。
ID/PASSの設定
ID/PASSを設定する方法を検討しました。
JitsiのWeb画面からは登録はできないようです。
調べたところ、Jitsiの構成要素のXMPPサーバーである、Prosodyにコマンド登録する必要があるようです。
[root@meet docker-jitsi-meet]# docker-compose exec prosody prosodyctl --config /config/prosody.cfg.lua register user meet.jitsi password
[root@meet docker-jitsi-meet]#
どうやら、ユーザー認証はうまくいったようです。
しかし、この状態だと、全員が、ID/PASSを入力しないと会議になりません。
これでは、社外の人と一時的に、Web会議する際に、毎回ID/PASSを発行する必要があり、利用に制約が生まれてしまいます。
ルームを作るときだけ認証が必要で、2人目からは認証不要にする設定
以下のマニュアルを参考にしました。
ちょっと困ったことに、全員ID/PASSが必要な設定の場合には、URL入力後すぐに、ID/PASSの入力画面が出てきますが、この設定にした場合には、名前入力後、ルームにログインした後に、ID/PASSが出るように認証のフローが変わります。(ここで悩みました。)
# Enable authentication
#ENABLE_AUTH=1
+ENABLE_AUTH=1
# Enable guest access
#ENABLE_GUESTS=1
+ENABLE_GUESTS=1
# Select authentication type: internal, jwt or ldap
#AUTH_TYPE=internal
+AUTH_TYPE=internal
+ENABLE_AUTO_LOGIN=1
ID/PASSを削除する(ログインユーザー削除)
リストに出ていないのが何故なのかは、私も知りたいです。OSSですからね。
この辺り、メーカー製品だと問い合わせできるので、さすがメーカー様との差があります。
[root@meet docker-jitsi-meet]# docker-compose exec prosody prosodyctl --config /config/prosody.cfg.lua unregister user meet.jitsi
[root@meet docker-jitsi-meet]#
また、ユーザーの追加や、削除を行った際には、以下でDockerの再起動が必要です。
この運用はちょっとまずいのかなと考えています。(後述)
[root@meet docker-jitsi-meet]# docker-compose stop
[+] Running 4/4
⠿ Container docker-jitsi-meet-jvb-1 Stopped 4.1s
⠿ Container docker-jitsi-meet-web-1 Stopped 3.6s
⠿ Container docker-jitsi-meet-jicofo-1 Stopped 4.0s
⠿ Container docker-jitsi-meet-prosody-1 Stopped 3.5s
[root@meet docker-jitsi-meet]# docker-compose up -d
[+] Running 4/4
⠿ Container docker-jitsi-meet-web-1 Started 1.2s
⠿ Container docker-jitsi-meet-prosody-1 Started 1.2s
⠿ Container docker-jitsi-meet-jicofo-1 Started 3.1s
⠿ Container docker-jitsi-meet-jvb-1 Started 3.1s
[root@meet docker-jitsi-meet]#
今後の課題
ユーザーの追加や削除など、コマンドで実施するのはいいとしても、システム再起動を要するのであれば、運用後の作業時間に様々な制約(問題)が生まれてしまいます。
例えば、Aさんが会議している状態で、新人のIDを登録したい場合、システム再起動が必要なると、Aさんの会議を中断させることになるため、誰も会議していない時間を狙ったユーザー管理になります。
→即時性のない、昔ながらのバッチ運用になってしまいます。
よって、通常の運用では、容易に困ったことになることが予想されます。
この辺りがうまくできていないのが、OSSの制限ですね。(Zoomはよくできています。)
というわけで、運用を考慮した仕組みを検討していきたいですね。
※仕事で使うなら、運用を検討したうえで、ちゃんとした製品の検討をお勧めします。
私なら、夜中にユーザー編集作業とかはちょっと避けたいです。
今回の所要時間
今回は、以下の理由でパラメタ設定だけにもかかわらず、時間がかかりました。
※しかし、これがOSSのコストなのだと考えていますし、利用者側に理解が必要な部分です。
- 接続テストの認証画面の表示の順番が異なることで、設定がうまくいっているか同課の判断ができなかったこと。
- ID/PASSを登録後にDocker再起動を忘れたために、反映できなかったこと
そういった、引っ掛かりがあって、5時間くらいの調査時間となりました。
Discussion