Azure ADにおけるアプリケーション統合とは②

この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

前回の記事ではAzure ADにおけるアプリケーション統合について、特にSAMLによるシングルサインオンについて紹介しました。

 

事前統合されたアプリケーションはギャラリーから簡単に追加することが出来ます。Azure ADのアプリケーション統合を用いる事により、アプリケーションはAzure ADの持つ強力なアクセス制御機能を利用できるようになります。これはMicrosoftの標準アプリケーションや、SaaSアプリケーションだけではなく、Azure App Serviceで作成した自作のWebアプリケーションでも同様です。

 

この記事ではWebアプリケーションのアプリケーション統合について、実例を見ながら使われている機能などを確認していきます。

 

App Service のアプリに認証を追加

App Serviceでは、認証機能を持たないWebアプリケーションに対し、とても簡単な設定でAzure ADの認証機能を持たせることができます。この際、Webアプリケーション側のコーディングは不要です。

 

まずは公開されているサンプルを利用し、ユーザ管理機能を持たない簡単なWebアプリケーションをデプロイしてみました。

 

現時点では、URLを知ってさえいれば誰でもこの画面にアクセスすることが出来ます。

 

このWebアプリケーションに、Azure ADによる認証機能を加えてみます。これはApp Serviceの画面上で簡単に設定可能です。これを行うことにより、Azure ADに認証されたユーザだけがこのWebアプリケーションにアクセスできるようになります。

 

App Serviceの管理画面にて「認証」ブレードを開きます。

「IDプロバーダーを追加」をクリックします。

 

IDプロバイダーには「Microsoft」を選択します。

 

次に、「Microsoft Graph のアクセス許可」という画面になりますが、ここは何も変更せず「保存」をクリックします。

 

これで設定は完了です。

実際に先ほどのWebアプリケーションにアクセスしてみましょう。

 

Azure ADのサインイン画面が出てくるようになりました。

 

初回アクセス時は「承諾」が求められます。

 

サインイン後、問題なくアクセスできました。

 

なお、Azure ADユーザがMFAを構成していれば、サインインの際に多様書認証が行われることになります。

 

このように、自作Webアプリケーションに対してもコーディング不要強力なアクセス制御機能簡単に加えることが可能になるのがアプリケーション統合の利点です。

 

 

Microsoft Graph APIについて

先ほどWebアプリケーションに認証を追加した際、「アクセス許可」のところでMicrosoft Graphというものが出てきました。

 

Microsoft Graph APIとは、Microsoft365やAzure ADなどのデータにアクセスすることができるAPIです

https://docs.microsoft.com/ja-jp/graph/use-the-api

 

今回の例だと、作成したWebアプリケーションにサインインしているユーザのプロファイルを読み取るためのアクセスを許可したことになります。

ここではユーザプロファイルのみアクセス許可しましたが、Microsoft Graph APIをつかうと、Microsoft365のTeamsのユーザデータや、会議室の空き状況など、Microsoftが持つ膨大なデータをアプリケーションで扱うことが出来るようになります。

 

Microsoft Graph APIを使うには、Azure ADの左側ナビゲーションより「アプリの登録」→「新規登録」を選択し、アプリケーションを統合しておく必要があります。※今回の例ではWebアプリケーションに「認証」機能を追加した際に、「アプリの登録を新規作成する」を選んだため、自動的にアプリケーション統合されました。

 

 

サービスプリンシパルオブジェクトとアプリケーションオブジェクト

Webアプリケーションに認証を追加したあとにAzure ADの「エンタープライズアプリケーション」メニューを見ると先ほどのWebアプリケーションが登録されています。

 

これは「サービスプリンシパルオブジェクト」とよばれるものです。

https://docs.microsoft.com/ja-jp/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object

サービス プリンシパル オブジェクトには、特定のテナント内でアプリが実際に実行できること、アプリにアクセスできるユーザー、アプリからアクセスできるリソースを定義します。

 

つまり、そのアプリに対するアクセス制御を構成するためのオブジェクトと言えます。

先ほどのWebアプリの例で言うと、この時点では同テナントのAzure AD認証を通ったユーザは誰でもアクセスすることができます。しかし、サービスプリンシパルオブジェクトに対して設定を行なうことで、特定のユーザおよびグループのみにアクセス許可を割り当てることができます。

 

サービスプリンシパルのプロパティ設定で「割り当てが必要ですか?」を「はい」に変更して保存すると、特定のユーザ、グループのみにアプリケーションへのアクセスを付与することが出来るようになります。

 

その他、条件付きアクセスの設定、シングルサインオンの設定などはこの「エンタープライズアプリケーション」ブレードのサービスプリンシパルオブジェクトの設定画面から行なうことにができます。

 

一方、Azure ADの「アプリの登録」を見てみると、「所有しているアプリケーション」タブに先ほどのWebアプリケーションが登録されているのがわかります。

これは「アプリケーションオブジェクト」とよばれるものです。

 

アプリケーションオブジェクトとはなんでしょうか?Microsoftのドキュメントを見ると、「サービスプリンシパルオブジェクトを作成するためのテンプレートである」との説明があります。

https://docs.microsoft.com/ja-jp/azure/active-directory/develop/app-objects-and-service-principals#application-object

 

「アプリケーションオブジェクト」にはAzure ADに統合するアプリケーションの定義情報を設定します。具体的には以下情報が含まれています。

名前、ロゴ、発行元
リダイレクト URI
シークレット (アプリケーションの認証に使用される対称キーまたは非対称キー)
API の依存関係 (OAuth)
発行済みの API/リソース/スコープ (OAuth)
アプリのロール (RBAC)
SSO のメタデータと構成
ユーザー プロビジョニングのメタデータと構成
プロキシのメタデータと構成

先ほど紹介したMicrosoft Graph APIのアクセス許可もこちらで行います。

 

「アプリの登録」→「新規登録」を行ってアプリケーションオブジェクトを作成した場合、サービスプリンシパルオブジェクトは自動作成されます。

 

まとめ

今回は、自作のWebアプリケーションをAzure ADにアプリケーション統合した場合の設定方法や、用語について見ていきました。

 

「アプリの登録」と「エンタープライズアプリケーション」の違いなど、若干分かりにくい構成になっていますが、これについては以下の記事が参考になります。

「エンタープライズアプリケーション」と「アプリの登録」の違いについて

 

いいね (この記事が参考になった人の数:4)
(↑参考になった場合はハートマークを押して評価お願いします)
読み込み中...

注意事項・免責事項

※技術情報につきましては投稿日時点の情報となります。投稿日以降に仕様等が変更されていることがありますのでご了承ください。

※公式な技術情報の紹介の他、当社による検証結果および経験に基づく独自の見解が含まれている場合がございます。

※これらの技術情報によって被ったいかなる損害についても、当社は一切責任を負わないものといたします。十分な確認・検証の上、ご活用お願いたします。

※当サイトはマイクロソフト社によるサポートページではございません。パーソルプロセス&テクノロジー株式会社が運営しているサイトのため、マイクロソフト社によるサポートを希望される方は適切な問い合わせ先にご確認ください。
 【重要】マイクロソフト社のサポートをお求めの方は、問い合わせ窓口をご確認ください