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

Azure Active Directory (Azure AD) の "アプリケーション" という用語の意味は誤解されやいものであり、裏付けとなるコンテキストが不足している場合は特にその可能性が高まります。 この記事の目的は、Azure AD アプリケーションの統合について概念的な側面と具体的な側面を、マルチテナント アプリケーションの登録および同意の例を示しながら明らかにして、この用語の意味をよりわかりやすくすることです。

概要

Azure AD アプリケーションとは、単なるソフトウェアのことではありません。 これは、アプリケーション ソフトウェアだけでなく、その Azure AD への登録 (ID 構成とも呼ばれる) も意味する概念的な用語です。Azure AD に登録することで、そのアプリケーション ソフトウェアは、実行時に認証および承認の "対話" に参加できるようになります。 定義上、アプリケーションはクライアント ロール (リソースの使用)、リソース サーバー ロール (クライアントへの API の公開)、またはその両方のロールで動作できます。 対話プロトコルは OAuth 2.0 承認付与フローによって定義されており、その目的は、クライアントとリソースがそれぞれリソースのデータに対してアクセス/保護を実行できるようにすることです。 次はもう&1; 段階掘り下げ、Azure AD アプリケーション モデルにおいて、アプリケーションが内部的にはどのように表されるのかを見てみましょう。

アプリケーションの登録

Azure portal でアプリケーションを登録すると、Azure AD テナントに、アプリケーション オブジェクトとサービス プリンシパル オブジェクトという&2; つのオブジェクトが作成されます。

アプリケーション オブジェクト

Azure AD アプリケーションは、その唯一のアプリケーション オブジェクトによって定義されます。アプリケーション オブジェクトは、アプリケーションの登録先である Azure AD テナント (アプリケーションの "ホーム" テナントと呼ばれます) 内にあります。 アプリケーション オブジェクトは、ID に関連するアプリケーションの情報を提供するオブジェクトであり、対応するサービス プリンシパル オブジェクトを派生させて実行時に使用するためのテンプレートでもあります。

アプリケーション オブジェクトはアプリケーションのグローバルな表現 (すべてのテナント用) であり、サービス プリンシパル オブジェクトはアプリケーションのローカルな表現 (特定のテナント用) と考えることができます。 アプリケーション オブジェクトのスキーマは、Azure AD Graph Application エンティティによって定義されています。 そのため、アプリケーション オブジェクトには、ソフトウェア アプリケーションとの間に 1 対 1 のリレーションシップがあり、対応する n 個のサービス プリンシパル オブジェクトとの間に 1 対 n のリレーションシップがあります。

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

サービス プリンシパル オブジェクトは、アプリケーション用のポリシーとアクセス許可を定義しており、実行時のリソースへのアクセスの際にアプリケーションを表す、セキュリティ プリンシパルの基となる情報を提供します。 サービス プリンシパル オブジェクトのスキーマは、Azure AD Graph ServicePrincipal エンティティによって定義されています。

Azure AD テナントで、テナントの保護対象のリソースに対してアプリケーションがアクセスできるようにするには、このテナントにサービス プリンシパルを作成する必要があります。 サービス プリンシパルは、このテナントのユーザーの所有リソースに対してのアプリケーションのアクセスを Azure AD で保護するための基盤となっています。 シングルテナント アプリケーションは、サービス プリンシパルが&1; つのみ (ホーム テナント内に) 存在します。 また、マルチテナント Web アプリケーションは各テナントにサービス プリンシパルがあります。そのテナントからの管理者やユーザーにはリソースにアクセスできるように同意が与えられています。 同意を得た後、サービス プリンシパル オブジェクトは将来の承認要求のために参照されることになります。

メモ

アプリケーション オブジェクトに加えたすべての変更は、アプリケーションのホーム テナント (アプリケーションが登録されたテナント) にだけ存在するサービス プリンシパル オブジェクトにも反映されます。 マルチテナント アプリケーションの場合は、コンシューマー テナントでアクセス権を削除し、もう一度アクセス権を付与するまで、そのコンシューマー テナントのサービス プリンシパル オブジェクトにアプリケーション オブジェクトへの変更が反映されることはありません。

次の図は、 HR アプリという名前のサンプル マルチテナント アプリケーションを基に、アプリケーションのアプリケーション オブジェクトと、対応するサービス プリンシパル オブジェクトの間のリレーションシップを表しています。 このシナリオには、次の&3; つの Azure AD テナントがあります。

  • Adatum - HR アプリを開発した会社が使用するテナント
  • Contoso - HR アプリのコンシューマーである Contoso という組織が使用するテナント
  • Fabrikam - Contoso と同じく HR アプリのコンシューマーである Fabrikam という組織が使用するテナント

Relationship between an application object and a service principal object

前の図でのステップ 1. は、アプリケーションとサービス プリンシパル オブジェクトを、アプリケーションのホーム テナント内に作成するプロセスです。

ステップ 2. では、Contoso と Fabrikam の管理者が同意を終えると、それぞれの会社の Azure AD テナント内にサービス プリンシパル オブジェクトが作成され、それに管理者が付与したアクセス許可が割り当てられます。 HR アプリは、個々のユーザー用として、ユーザーによる同意を許可するように構成/設計することができる点にも注目してください。

ステップ 3 では、HR アプリケーション (Contoso と Fabrikam) のコンシューマー テナントにそれぞれ独自のサービス プリンシパル オブジェクトが作成されます。 それぞれ実行時におけるアプリケーションのインスタンスの使用を表し、それぞれの管理者によって同意されたアクセス許可によって管理されます。

次のステップ

Azure AD Graph API を通じて、OData Application エンティティによって表されるアプリケーションのアプリケーション オブジェクトにアクセスできます。

Azure AD Graph API を通じて、OData ServicePrincipal エンティティによって表されるアプリケーションのサービス プリンシパル オブジェクトにアクセスできます。