こんにちは。
最近はAWS上にプライベートなサイトを構築したりしています。 ここで問題になるのは、そのサイトの認証認可です。
今回のプロジェクトでは毎回VPNやSSHに接続しなくともアクセスできる手軽さを追い求めたいと考えています。 ということはIPSecやSSHのレイヤではなく、HTTPのレイヤで、できるだけ安全かつ手軽に認証を行いたいという欲求があります。
HTTPのレイヤで認証を行うとなると、一番最初に出てくるのはBasic認証やDigest認証でしょう。 もちろんこれらも使いやすく便利な認証方法ですが、このサイトの閲覧のためだけにユーザ名とパスワードを新規で発行するのは基本的には面倒です。 また、組織の管理者の方であれば、セキュリティの担保や手軽さのために、組織で運用しているGoogleやMicrosoftなどのアカウントを利用したい、というのはよくある話ではないでしょうか。
ということで、今回はALBにOpenID Connect（OIDC）を利用して、簡単にMicrosoftアカウントでの認証を導入していきたいと思います。 なお、Googleで認証をさせたい！という方は、こちらの記事がおすすめです。
導入
Microsoftのアプリ登録
まずはAzure portalから、アプリケーションの登録が必要です。
アプリケーションの登録画面で、アプリケーション名とリダイレクトURIを設定して登録しましょう。
リダイレクトURIには、 https://{ALBのドメイン}/oauth2/idpresponse を設定しましょう。
アプリケーションの登録が済んだら、作成したアプリケーションの詳細画面から証明書とシークレットを選択し、新しいクライアントシークレットを作成します。
ALBの作成
次にALBを作成します。
これは通常通り、HTTPSに対応したALBを作成すればOKです。 事前にACMで証明書を発行し、ALBに登録しましょう。 また、独自ドメインを利用する場合は、ALBへのCNAMEをDNSレコードに追加しておきましょう。
設定
ALBの設定
ここまで終わったら、いよいよALBにOIDCの設定をしていきます。
作成したALBのHTTPSリスナーを選択し、編集をクリックして編集画面に入ります。
Add ActionからAuthenticateを選択し、Identity providerをOIDCに設定します。
Client IDとClient secretは先ほど作成したMicrosoftのアプリのものを入力します。
他の空欄は、 $ curl https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration の結果出てくるJSONから適切なものを探し出し、入力します。
URLの {tenant} のところにはMicrosoftのアプリのテナントIDが入ります。
すべてが入力し終わったら、Save changesをクリックし、変更を保存しましょう。
これで、ALBでMicrosoftアカウントを利用した認証を行うことができるようになりました。 ALBにアクセスすると、Microsoftのログイン画面が表示されるようになっていると思います。
認可
ここまでで認証はできました。 では実際にアクセスの認可を与えるのは、どのようにしていけばよいでしょうか。
これは様々なやり方があるかと思いますが、今回はEC2に構築するアプリケーション側でALBが付与したヘッダを処理することにより、細かく認可を制御できるようにしていきましょう。
EC2（アプリケーション）側でヘッダを処理する
今回は、Rustでアプリケーションサーバを構築する想定で話を進めていきます。
ALBからは x-amzn-oidc-data ヘッダにJWT形式でユーザの認証データが送られてきます。
これを参照して、認証されたユーザのメールアドレスを取り出すプログラムを書いていきましょう。
ソースコードはこちらのリポジトリにあります。
実装はRust製WebフレームワークRocketのFairingで行っています。
とりあえず今回はメールアドレスを出力するところで力尽きてしまいましたが、ここで取り出したメールアドレスを利用すれば認可に利用することができそうです。
おわりに
以上でMicrosoftアカウントを利用した認証認可の導入は完了です。
最後は駆け足になってしまいましたが、大体の流れはつかんでいただけたのではないかと思います。 詳しくは下記参考文献に詳しく載っているので、そちらも併せてご参照ください。