この記事は 認証認可技術 Advent Calendar 2019 の 25 日目の記事です．
背景説明の割合が多いですが，事例紹介という側面も持たせたいと考えました．もし興味がございましたら，一読いただけますと幸いです．
実際に行なった技術的な設定については，こちら からすぐにお読みいただけます．
背景
筆者が所属する大学にはおよそ 80 のクラブ団体があり，これを6つの部局で所管しています．これらの部局は高校までの生徒会に近く，それぞれ体育系・文化系などといった観点から分けられています．
ここでは，文化系団体を所管する部局の業務効率化に乗り出し，G Suite アカウントを使ってログインできるシステムを導入して，最終的に成功した話を紹介したいと思います．
従来の状況
まず，文化系団体を所管する部局では下記のような業務があります．
-
文化系団体の部長を集めた会議の実施（毎月）
- 団体の出席状況の把握
- 新規クラブ団体の設立に伴う議論
- 大学からのクラブ運営費に関する説明
- 毎月の活動計画書・施設使用希望用紙の配布
- 窓口における学生対応
- 団体結成に関する各種相談の受け付け
- 予算・決算に関する各種事務手続き
- 活動計画書・施設使用希望用紙の受け付け
これらは説明のために抜粋した業務の一部ですが，特に太字で示した業務はコストが高いものとなっています．特に会議については，活動計画書等の用紙配布のためだけに実施されている側面が強く，多くは15分程度（出欠確認等を除くと実質5分程度）で終了します．
改善するポイントの整理
当然ながら，毎月ある会議をどうにかしようという結論にいたりました．そして，従来の**「会議と計画書・用紙配布はセット」**という考えを改めることにしました．具体的には，
- 会議の目的を十分に精査し，妥当性を検討する
- それこそ，計画書・用紙配布のためだけに学生を招集しない
- 会議は必要なときに必要なだけ実施する（不定期への転換）
- 新規クラブ団体の設立に関する話が持ち上がったとき
- 特に説明が必要な話が出てきたとき
というイメージです．当然といえば当然なのですが，10年以上も同じだった流れを変えるには，このくらい当たり前なことから触れていくことが重要であると考えました．
さらに，業務内容・改善したいポイントから，具体的に必要な機能について検討しました．
- 部局がデータをアップロードでき，学生が任意のタイミングでダウンロードできること
- 学生がデータをアップロードでき，部局が任意のタイミングでダウンロードできること
- 学生がアップロードしたデータについて，部局が提出日時を確認できること
改善に向けた技術・事例に関する調査
直前で整理した必要な機能をもとに調査を開始した結果，Moodle 1 という OSS に行き着きました．Moodle は LMS （Learning Managing System）の一種で，大学をはじめとする教育機関で広く活用されています．本学も例外ではなく，全学的な授業支援システムとして導入されています．
Moodle は LMS という特性上，授業の管理に特化したものとなっています．例えば，
- 授業で使う資料を Web 上で配付できる
- 課題の提出を受け付けることができる
- いつ提出されたかを把握できる
- 提出期限を定めることができる
- 授業運営に有用な機能をモジュールとして拡張できる
- 授業の出席管理機能を追加できる
ということができます．これらの機能はたいへん都合がよく，改善したいポイントをすべて押さえられています．また，副次的な効果として，学生に対する教育コストの削減も狙えると考えられます．先述の通り，Moodle は本学も全学的に導入しており，基本的な操作に関する資料作成が不要であるためです．
以上より，業務効率化を実施するにあたって Moodle を導入することにしました．また，長期運用を前提にするため LTS（Long Term Service）リリース 2 に指定されているバージョン（3.5, 執筆時点のマイナーバージョンは 3.5.9+）を選択しました．
Moodle のインストール
Moodle のインストールについては Installing Moodle 3 を参考に行ないました．
アカウント情報の配布に関する問題の発生
Moodle のインストールを含む各種設定を終え，実際に運用できると判断した矢先に，アカウントに関する問題に直面します．
当初，ID とパスワードの情報を配布すれば運用を開始できると考えていましたが，そもそも配布方法については検討していませんでした．アカウントを配布する際には安全性の観点から本人確認が必要です．学生証による本人確認の実施も検討しましたが，そこまでの時間も残されていませんでした．
G Suite アカウントを用いたログイン
更に調査を進めると，Moodle は OAuth 2 4 による認証ができることが判明しました 5．本学の構成員は G Suite アカウントが発行されているため，活用できると考えられます．また，既に発行済みのアカウントを活用することで，
- ID とパスワードの配布方法について悩む必要がない
- 日常的に使用しているアカウントであるため，問題が起こりにくい
- パスワード忘れ等が発生しても，別部署の通常業務に含まれているためコストが変わらない
というメリットがあります．
以上より，G Suite アカウントでログインできる Moodle の設定をすることとしました．
技術的な各種設定
長々と背景について書いてしまいましたが，ここからが本題です．
今回の設定では，最低限 G Suite のアカウントでログインできることを目標にします．
セキュリティをはじめ，実運用には向かない設定も含まれます（主に「認証・認可」に関する設定が不十分です．）ので，ご留意ください．
Google API Console 上での設定
プロジェクトの作成
まず，Google API Console 上でプロジェクトを作成する必要があります．
Google API Console を開くと，次のような画面になります．
このうち，左上の組織名の部分（赤枠で囲っている部分）をクリックします．
そうすると，次のような画面が出てきます．
ここで，右上の「新しいプロジェクト」をクリックしてください．
ここから，プロジェクト作成画面となります．
プロジェクト名はわかりやすい名前を，組織は選択可能なものを選択してください．本学では，大学のドメイン名がそのまま選択可能な組織となっていました．
必要事項の入力が終わったら，「作成」ボタンをクリックしてください．
同意画面の作成
OAuth クライアント ID を作成していくことになるのですが，そのためには同意画面を設定しておく必要があります．
左のメニューから「OAuth 同意画面」をクリックしてください．遷移先の画面は次のようになっています．
必要に応じてユーザタイプを選択することになるのですが，今回は外部として登録したいと思います．
「作成」をクリックして先に進むと，次のような画面に遷移します．
ここで，下記のように必要事項を入力していきます．
| 項目名 | 内容 | 例 |
|---|---|---|
| アプリケーション名 | 同意を求めるアプリの名前 | Test Moodle |
| アプリケーションのロゴ | ユーザがアプリを認識しやすいように同意画面に表示される画像 | 今回は指定しない |
| サポートメール | ユーザサポートに関する同意画面で表示されるメールアドレス | example@example.ac.jp |
| 承認済みドメイン | 使用するアプリのトップレベルドメイン名 | example.ac.jp |
入力が終わったら「保存」をクリックしてください．
認証情報の作成
同意画面の設定が終わったあとは，ダッシュボードに戻ってください．
ここから必要な設定をしていきますので，左のメニューから「認証情報」をクリックしてください．
遷移先の画面では，各種認証情報を作成することができます．今回は OAuth クライアント ID を作成していきます．赤枠で囲まれたところをクリックしてください．
その後，次のような画面に遷移します．
ここでは，「ウェブアプリケーション」を選択してください．そうすると，次のような画面に切り替わります．
ここでは，下記のように設定してください．
| 項目名 | 内容 | 例 |
|---|---|---|
| 名前 | クライアント ID の名前 | test-moodle-oauth |
| 承認済みの JavaScript 生成元 | JavaScript 生成元の URI | https://moodle.example.ac.jp |
| 承認済みのリダイレクト URI | 認証後にリダイレクトする先のパス | https://moodle.example.ac.jp/admin/oauth2callback.php |
特に，承認済みのリダイレクト URI を入力する際は注意してください．今回は https://moodle.example.ac.jp/ で Moodle にアクセスできる前提で入力していますが，例えば https://www.example.ac.jp/moodle/ で Moodle にアクセスするような場合ですと，承認済みのリダイレクト URI は https://www.example.ac.jp/moodle/admin/oauth2callback.php とする必要があります．
入力後，「作成」をクリックしてください．そうすると，次のように「クライアント ID」と「クライアントシークレット」が発行されます．
これらの値は Moodle 上での設定時に必要となるので，控えておいてください．
（補足）同意画面の未設定について
認証情報を作成する前に，前述の通り同意画面を設定する必要があります．もし次のような警告が出た場合は，同意画面の作成からやり直してください．
Moodle 上での設定
さて，ここからは Moodle 上で設定します．まずは，管理者権限のあるアカウントでログインしてください．
その後，「サイト管理」から「サーバ」のタブを選択し，「OAuth 2サービス」をクリックしてください．デフォルトの表示ですと，次のような画面になります．
クリックして遷移すると，次のような画面になります．
ここから，「新しい Google サービスを作成する」をクリックしてください．そうすると，次のような画面になります．
この画面で必要な設定は次の通りです．
| 項目名 | 内容 | 例 |
|---|---|---|
| クライアント ID | 控えておいたクライアント ID を指定 | 123456789012-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com |
| クライアント秘密鍵 | 控えておいたクライアントシークレットを指定 | 0-xxxxxxxxxxxxxxxxxxxx |
| メール確認を必要とする | メールアドレスの確認有無 | 今回はチェックを外します |
これらの設定が終わり保存すると，次のような画面に遷移します．
OAuth 2 ログインの有効化
これまでに，様々な設定を行なってきましたが，このままですと OAuth 2 用のログインボタンが表示されません．そこで，ログインの有効化（ログインボタンの表示）を行なっていきます．
「サイト管理」から「プラグイン」／「認証」／「認証管理」と辿ってください．そうすると，次のような画面が表示されます．
この画面の OAuth 2 のところにある赤枠の部分（目のマークに斜線を引いているボタン）をクリックすることによって，有効化することができます．
実際にログイン画面を出すことによって，有効化されたことを確認できます．
ログインする際にはこの赤枠の部分をクリックし，ログインすることになります．
おわりに
今回は Moodle に G Suite のアカウントを使ってログインすることを目標にしました．これまでに行なってきた設定をすることで，実際にログインできる環境を構築しました．
今回は認証に関する設定を最小限にしているため，実際の運用ではそのまま当てはまらないこともあるかと思います．例えば，現在の設定では，Moodle 上に該当するユーザアカウントが存在しないにも関わらず G Suite のアカウントでログインを試みた場合，Moodle 上ではアカウントが新規作成されます．また，ログインに使用できるドメイン名も制限していないため，@gmail.com のような自由に取得できるアカウントでもログインが可能です．
実際に運用する場合は，認証に関する設定についての見直しが必要です．
-
"About Moodle - MoodleDocs," https://docs.moodle.org/35/en/About_Moodle, 参照 Dec. 22, 2019. ↩
-
"Releases Moodle - MoodleDocs," https://docs.moodle.org/dev/Releases, 参照 Dec. 22, 2019. ↩
-
"Installing Moodle - MoodleDocs," https://docs.moodle.org/35/en/Installing_Moodle, 参照 Dec. 22, 2019. ↩
-
"D. Hardt, "The OAuth 2.0 Authorization Framework," IETF,https://tools.ietf.org/rfc/rfc6749.txt, Oct. 2012. ↩
-
"OAuth 2 authentication - MoodleDocs," https://docs.moodle.org/35/en/OAuth_2_authentication, 参照 Dec. 22, 2019. ↩