Azure AD で認証された Web App のアクセス制御
はじめに
こちらの記事では Azure Web App を利用するユーザーを Azure AD で認証するように構成しましたが、このままではテナントに登録されている全てのユーザーがアクセス可能な状態です。同一組織に所属する全てのユーザーが使えるシステムというのも無いわけではないですが、特に業務系のシステムでは「特定のユーザーのみに利用を制限する」、さらには「ユーザーの属性情報を元にアプリの挙動を変える」といった要件もあると思います。
本記事では前回書ききれなかった内容について紹介したいと思います。
特定のユーザーのみにアクセスを制限する
ユーザーに対するアクセス制限を行うためには、 Azure AD 側でアプリケーションに対して「ユーザーの割り当て」を設定します。この設定により、割り当てられた特定のユーザーに対してのみ当該アプリケーション向けのトークンが発行されるようになります。
既定ではAzure AD に登録されたアプリケーションはユーザーの割り当てが不要になっており、同じテナントに所属する全てのユーザーが利用可能な状態になっていますので、まずこの設定を変更します。以下のようにアプリケーションのプロパティ画面で「ユーザーの割り当てが必要ですか？」を「はい」に切り替え、次に当該アプリケーションに割り当てるユーザーを追加していきます。
この状態でアプリケーションにアクセスすると、割り当てられたユーザーでサインインすると正常にアクセスできますが、割り当てられていないユーザーでサインインした場合にはアクセスが拒否されることが確認できます。
アプリケーションでユーザー情報を利用する
Azure Web App に配置されたアプリケーションは、フロントエンドで認証されたユーザーのリクエストのみを受信します。この際フロントエンド側は「X-MS-*」というプレフィックスが付いたいくつかのカスタム HTTP ヘッダーを付与してくれますので、アプリケーション側ではこれを解析することで認証情報を利用することが可能です。
ヘッダー情報の確認
実際に送信されてくるヘッダー情報を確認するには、アプリケーション側で画面に表示させてしまうのが簡単でしょう。例えば以下のような aspx ないしは php ファイルを Web App に配置することで、アプリケーションが実際に受け取った HTTP ヘッダーを確認することが可能です。
<!-- aspx file -->
<%@ Page Trace="true" %>
<!-- php file -->
<?php phpinfo(); ?>
あわせて Web ブラウザーのデバッガー機能を使用してネットワーク通信の内容も確認すると、ブラウザーからは X-MS-* という名前のヘッダーが送信されていないことが分かります。Azure AD から受け取ったトークン自体は Web App がセッション情報として管理しており、リクエストを受け取った際に X-MS-* ヘッダーに展開してアプリケーションに送信します。Web ブラウザーは Cookie を使用して認証セッションを維持していることになります。
X-MS-CLIENT-PRINCIPAL- から始まるヘッダー情報からユーザー ID が取得できますので、これをキーとしてユーザーのプロファイル DB を構築したり、条件分岐することで挙動を変えることが可能かと思います。
トークンの中身
ただヘッダーだけではやはり内容に乏しくイマイチ使い勝手が良くありません。では X-MS-TOKEN-AAD- から始まるヘッダー情報には何が入っているのでしょうか。以下のサイトで JSON Web Token のデバッガーが提供されていますので、こちらに「X-MS-TOKEN-AAD-ID-TOKEN」の値を入力すると中身を確認することができます。
https://jwt.io/ 
多少はマシになりましたが、これだけでは「ようこそ XXX さん！」の表示くらいにしか使えなさそうですね・・・。これ以上の詳細なユーザー情報を取得するためには Graph API などを使用する必要がありますが、それはまた別途記事にしたいと思います。