Azure Active Directory のモバイル サービス向け機能でロール ベースのアクセス制御が可能に
このポストは、3 月 4 日に投稿された Roles-Based Access Control in Mobile Services and Azure Active Directory の翻訳です。
編集メモ: 今回は、Matthew Henderson の記事をご紹介します。
マイクロソフトは 11 月に、モバイル サービスの ID プロバイダーとして機能する Azure Active Directory (AAD) のプレビュー版を発表 (英語) しました。その目的は、企業の開発者が従業員向けモバイル アプリケーションを簡単に構築できるようにすることです。現在プレビュー版をご利用中のお客様は、基本的な認証はもちろんですが、ユーザーのタイプを識別して認証の意思決定を行うことが必要な場合が多くあったと思います。ロール ベースのアクセス制御 (RBAC) では、ユーザーが保持するロールに対して権限を割り当てることにより、可能な操作の範囲をユーザーのタイプ別に適切に定義することができます。幸いにも、基本的な RBAC は Azure モバイル サービスに簡単に追加することができます。この記事では、その方法についてご紹介します。
この手順に従うには、 Azure Active Directory のモバイルサービス向け統合機能のプレビュー版を登録する必要があります。登録を希望される場合は、MobileServices@microsoft.com まで電子メールをお送りください。
背景
セールス チーム向けのアプリケーションを開発する場合について考えてみましょう。アプリケーションにアクセスするには、会社のディレクトリのメンバーに所属しているだけでなく、セールス グループに割り当てられている必要もあります。ここで、サーバー側に追加しなければならないロジックについて考えます。認証されたセールス チームのメンバーのみがアプリケーションにアクセスできるようにしましょう (モバイル サービスで Azure Active Directory 認証を初めてお使いになる場合は、入門チュートリアル (英語) を参考にしてください)。
基本的なアプローチとしては、Azure AD テナント内のユーザーのセキュリティ グループ メンバーシップを活用します。AAD にはロールとグループのどちらの概念もありますが、今回のシナリオでは、適切なユーザー メンバーシップを持つ既存のグループを使用します。グループの管理は、Azure AD テナントと同期されるオンプレミスの AD テナントから行います。Office 365 や Windows Intune のお客様は、オンプレミスの Active Directory と同期されたディレクトリを設定することで、多くのメリットを得ることができます (これらのテナントを利用してモバイル サービスを構築することもできます)。
今回は「パスワード同期」オプションを利用しますが、複数のシナリオがサポートされています。実際に、AAD の設定で ADFS を指定すると、優れたハイブリッド シナリオを実現することができます。これらのオプションを試してみたい場合は、Azure VM 上で Windows Server 2012 R2 Datacenter を実行して、Active Directory ドメイン サービスのロールをインストールしてください。その後、ディレクトリ同期の手順に従ってください。
グループの作成
私のディレクトリ内に、いくつかのユーザー (Alice、Bob、Carol、Dave) と、「Sales」ドメイン セキュリティ グループを作成しました。Alice と Bob をこのグループのメンバーに含めました。Carol と Dave はメンバーから除外されているため、私のアプリケーションへのアクセス権はありません。他の設定は既定のままにします。
Azure モバイルサービスへの接続
これで、アプリケーション バックエンドを構築する準備が整いました。Azure モバイル サービスで、提供された認証ロジックの他に、追加の認証ロジックを使用してそれぞれのスクリプトや API を保護したいと思います。さらに、セキュリティを強化するために、保護された各エンドポイントに対するアクセス権を [Only Authenticated Users] に設定します。
複数のスクリプトで実行するロジックを構築しているので、モバイル サービスの Git リポジトリ (英語) の共有スクリプトのセクションにコードを配置します。スクリプト名は rbac.js です。
グループ メンバーシップを決定するには、最初に AAD の Graph API にアクセスできるようにする必要があります。この設定については、こちらのブログ記事 (英語) とサンプル (英語) を参照してください。以下のようにコードを記述していきます。
Graph アクセス トークンを取得したら、IsMemberOf (英語) Graph エンドポイントを呼び出す必要があります。これにより、指定されたユーザーが特定のグループのメンバーかどうかが確認されます (推移性のメンバーシップを含む)。確認先のスクリプトからユーザー ID を取得することができます。すべてのテーブル スクリプトはユーザー オブジェクトを明示的に受け取るため、request.user にアクセスすることにより、カスタム API からユーザー ID を取得することができます。グループ ID は管理ポータルで有効に利用できるため、取得する必要があります。Azure AD テナントを表示して、グループ タブを開いてグループを選択し、[CONFIGURE] タブでオブジェクト ID をコピーします。
簡単に利用できるように、フレンドリ名を持つ共有スクリプトから値をエクスポートします。
ここで、AAD の isMemberOf エンドポイントの呼び出しをラップする関数を記述します。先に述べたように、取得した userID と groupID の両方が必要です。要求には、取得したアクセス トークンも含める必要があります。
プログラミング モデルを少し単純化して、モバイル サービスのユーザー オブジェクト (objectID の取得先) とグループ ID だけを要求します。Graph トークンを取得して呼び出しが実行されるように、適切にラップします。運用環境では、このトークンを毎回フェッチする代わりに、キャッシュすることができます。トークンには有効期限の値が含まれているので、その期限に基づいて新しいトークンをフェッチする時期を決定することができます。
ここでは共有スクリプトについて説明しました。次に、各スクリプトを RBAC で保護するには、いくつかの行を追加してコールバックでスクリプトを実行する必要があります。以下は、テーブルの読み取りの例です。
まとめ
まとめに入ります。以上の手順で、アプリケーションを必要としている一部の従業員のみに利用を適切に制限することができました。ここから RBAC のさまざまなシナリオを構築することができます。特定のユーザーのクライアント UI を区別したい場合は、1 つの簡単な方法として、メンバーシップの確認をカスタム API として公開し、ログイン直後に呼び出せるようにする方法があります。
Azure Active Directory では、グループのサポートを利用して高度な設定を行うことができます。また、管理ポータルからさまざまな操作を直接行うことが可能です。AAD の Premium ユーザーの方は、新しいセルフサービス型のグループ管理サポート (英語) についてもご確認ください。
企業向けモバイル アプリケーションの開発にご興味をお持ちの方は、新しいモバイル サービスの .NET バックエンドのプレビュー版 (英語) もお試しください。現在、AAD のビルトイン サポートは提供されていませんが、間もなく提供される予定ですのでご安心ください。
繰り返しになりますが、AAD のプレビュー版への参加にご興味をお持ちの場合やご質問がある場合は、mobileservices@microsoft.com まで電子メールでお問い合わせください。
その他の機能やシナリオについてご希望がある場合は、こちらのフォーラム (英語) からご意見をお寄せください。