次の方法で共有


アプリケーションを Microsoft Entra ID に追加する方法と理由

Microsoft Entra ID には、2 つの表現のアプリケーションがあります。

  • アプリケーション オブジェクト - 例外はありますが、アプリケーション オブジェクトはアプリケーションの定義と考えることができます。
  • サービス プリンシパル - アプリケーションのインスタンスと考えることができます。 一般的に、サービス プリンシパルはアプリケーション オブジェクトを参照し、1 つのアプリケーション オブジェクトは複数のディレクトリの複数のプリンシパルによって参照されます。

アプリケーション オブジェクトの概要とその由来

Microsoft Entra 管理センターでは、アプリケーション オブジェクト[アプリの登録] エクスペリエンスで管理できます。 アプリケーション オブジェクトは、Microsoft Entra ID に対するアプリケーションについて記述します。アプリケーション オブジェクトはアプリケーションの定義と考えることができます。これにより、サービスは設定に基づいてアプリケーションにトークンを発行する方法を知ることができます。 他のディレクトリ内のサービス プリンシパルをサポートするマルチテナント アプリケーションであっても、アプリケーション オブジェクトはそのホーム ディレクトリにのみ存在します。 アプリケーション オブジェクトには、次のいずれかを含めることができます (ただし、これらに限定されません)。

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

アプリケーション オブジェクトは、以下のような複数の経路で作成できます。

  • Microsoft Entra 管理センターでのアプリケーションの登録
  • Visual Studio を使用して新しいアプリケーションを作成し、Microsoft Entra 認証を使用するように構成する
  • 管理者がアプリ ギャラリーからアプリケーションを追加するとき (これによってサービス プリンシパルも作成されます)
  • Microsoft Graph API または PowerShell を使用して新しいアプリケーションを作成する
  • Azure でのさまざまな開発者エクスペリエンスや、デベロッパー センターでの API エクスプローラー エクスペリエンスなど、その他多数

サービス プリンシパルの概要とその由来

サービス プリンシパルは、Microsoft Entra 管理センターの [エンタープライズ アプリケーション] エクスペリエンスで管理できます。 サービス プリンシパルは、実際には Microsoft Entra ID に接続するアプリケーションを制御するものであり、ディレクトリ内のアプリケーションのインスタンスと考えることができます。 どのアプリケーションでも、最大で 1 つの ("ホーム" ディレクトリに登録されている) アプリケーション オブジェクトと、アプリケーションが動作する各ディレクトリ内のアプリケーションのインスタンスを表す 1 つ以上のサービス プリンシパル オブジェクトを持つことができます。

サービス プリンシパルには、以下を含めることができます。

  • アプリケーション ID プロパティを使用したアプリケーション オブジェクトへの参照
  • ローカル ユーザーとグループ アプリケーション ロールの割り当ての記録
  • ローカル ユーザーとアプリケーションに許可された管理アクセス許可の記録
    • 例: 特定のユーザーの電子メールにアクセスするためのアプリケーションに対するアクセス許可
  • 条件付きアクセス ポリシーを含むローカル ポリシーの記録
  • アプリケーションの代替ローカル設定の記録
    • 要求変換ルール
    • 属性マッピング (ユーザーのプロビジョニング)
    • ディレクトリ固有のアプリ ロール (アプリケーションがカスタム ロールをサポートする場合)
    • ディレクトリ固有の名前またはロゴ

アプリケーション オブジェクトと同様に、サービス プリンシパルも以下のような複数の経路で作成できます。

  • ユーザーが Microsoft Entra ID と統合されたサードパーティ アプリケーションにサインインするとき
    • サインイン中、ユーザーのプロファイルにアプリケーションがアクセスするための許可とその他のアクセス許可を与えるように求められます。 最初のユーザーがそれに同意した時点で、アプリケーションを表すサービス プリンシパルがディレクトリに追加されます。
  • ユーザーが Microsoft 365、Microsoft Entra ID、Microsoft Azure などの Microsoft オンライン サービスを使用またはサインインする場合。
    • Microsoft サービスを初めて使用する場合、サービスの配信に使用されるさまざまな Microsoft サービス ID を表す 1 つ以上のサービス プリンシパルがディレクトリに作成される場合があります。 この "Just-In-Time" プロビジョニングは、多くの場合、バックグラウンド プロセスの一部として、いつでも行われる可能性があります。 まれに、作成される Microsoft サービス プリンシパルに、"ディレクトリ 閲覧者" などのディレクトリ ロールが割り当てられることもあります。
    • SharePoint Online などの一部の Microsoft サービスでは、ワークフローを含むコンポーネント間で安全に通信できるようにするために、継続的にサービス プリンシパルが作成されます。
  • 管理者がアプリ ギャラリーからアプリケーションを追加するとき (これによって基になるアプリケーション オブジェクトも作成されます)
  • Microsoft Entra アプリケーション プロキシを使用するアプリケーションを追加する
  • SAML またはパスワード SSO を使用してアプリケーションを SSO 用に接続する
  • Microsoft Graph API または PowerShell でプログラムを使用する

アプリケーションには、ホーム ディレクトリ内に 1 つのアプリケーション オブジェクトがあり、そのアプリケーション オブジェクトは、アプリケーションが動作する各ディレクトリ (アプリケーションのホーム ディレクトリを含む) 内の 1 つ以上のサービス プリンシパルから参照されます。

アプリケーション オブジェクトとサービス プリンシパル間のリレーションシップの表示

上の図では、Microsoft はアプリケーションを発行するために使用する 2 つのディレクトリを内部的に保持しています (左側)。

  • 1 つはマイクロソフトのアプリ用 (Microsoft サービス ディレクトリ)
  • 1 つは事前に統合されたサードパーティのアプリケーション用 (アプリ ギャラリー ディレクトリ)

Microsoft Entra ID と統合するアプリケーションのパブリッシャー/ベンダーには、発行ディレクトリが必要です (右側の "サービスとしてのソフトウェア (SaaS) ディレクトリ")。

自分自身を追加するアプリケーション (この図では "App (yours) " と示されている) には、次のアプリケーションが含まれます。

  • 開発したアプリ (Microsoft Entra ID と統合)
  • SSO 用に接続したアプリ
  • Microsoft Entra アプリケーション プロキシを使用して発行したアプリ

エラーと例外

  • すべてのサービス プリンシパルがアプリケーション オブジェクトを逆参照するわけではありません。 Microsoft Entra ID が最初に構築された時点では、アプリケーションに提供されるサービスははるかに限定的であり、サービス プリンシパルはアプリケーション ID を確立するのに十分でした。 元のサービス プリンシパルは、Windows Server Active Directory サービス アカウントとよく似ていました。 このため、現在でも、先にアプリケーション オブジェクトを作成せずに、Microsoft Graph PowerShell を使用するなど、異なる経路でサービス プリンシパルを作成できます。 Microsoft Graph API では、サービス プリンシパルを作成する前に、アプリケーション オブジェクトが必要です。
  • 現在、このような情報の中にはプログラムによって公開されていないものがあります。 次の情報は UI でのみ使用できます。
    • 要求変換ルール
    • 属性マッピング (ユーザーのプロビジョニング)
  • サービス プリンシパル オブジェクトおよびアプリケーション オブジェクトの詳細については、Microsoft Graph API のリファレンス ドキュメントを参照してください。

アプリケーションがMicrosoft Entra ID と統合される理由

アプリケーションは、次のような Microsoft Entra ID が提供するサービスを利用するために Microsoft Entra ID に追加されます。

  • アプリケーションの認証と承認
  • ユーザーの認証と承認
  • フェデレーションまたはパスワードを使用するSSO
  • ユーザーのプロビジョニングと同期
  • ロール ベースのアクセス制御 (RBAC) - ディレクトリを使用して、アプリケーション内でロールに基づく承認チェックを実行するためのアプリケーション ロールを定義します
  • OAuth 承認サービス (Microsoft 365 や他の Microsoft アプリケーションによって API/リソースへのアクセスを承認するために使用されます)
  • アプリケーションの発行とプロキシ。プライベート ネットワークからインターネットにアプリケーションを発行します。
  • ディレクトリ スキーマ拡張機能属性 - サービス プリンシパルとユーザー オブジェクトのスキーマを拡張し、Microsoft Entra ID で追加データを格納します

Microsoft Entra インスタンスにアプリケーションを追加する権限のあるユーザー

既定ではディレクトリ内のすべてのユーザーが、開発しているアプリケーション オブジェクトを登録する権限を持ち、同意によって共有するアプリケーションまたは組織データにアクセスできるアプリケーションを決定できます。 ディレクトリ内で、アプリケーションにサインインし、同意を許可した最初のユーザーの場合、テナントにサービス プリンシパルが作成されます。 それ以外の場合、同意の許可情報は既存のサービス プリンシパルに格納されます。

アプリケーションへの登録と同意をユーザーに許可することは、最初は心配かもいれませんが、以下の点に留意してください。

  • アプリケーションは、長い間、登録されたりディレクトリに記録されたりしなくても、ユーザー認証に Windows Server Active Directory を利用することができました。 現在では、いくつのアプリケーションがどのような目的でディレクトリを使用しているかを正確に認識できるようになっています。
  • これらの責任をユーザーに委ねることで、管理主導のアプリケーション登録と公開プロセスの必要がなくなります。 Active Directory フェデレーション サービス (ADFS) では、開発者に代わって管理者が証明書利用者としてアプリケーションを追加することが必要な場合がありました。 今では開発者がセルフ サービスできます。
  • ユーザーがビジネス目的で組織のアカウントを使用してアプリケーションにサインインするのは良いことです。 後でユーザーが組織を離れると、自動的に使用していたアプリケーションのアカウントにアクセスできなくなります。
  • どのようなデータがどのアプリケーションと共有されていたのかについての記録を残すのは良いことです。 データはかつてより移動性が高くなっており、誰がどのデータをどのアプリケーションと共有したかについての明確な記録があると便利です。
  • Microsoft Entra ID を OAuth に使用する API 所有者は、そのユーザーがアプリケーションに与えることができるアクセス許可および管理者が同意する必要があるアクセス許可を厳密に決定します。 ユーザーの同意はそのユーザー自身のデータと機能に限定されますが、管理者だけはより大きな範囲とより重要なアクセス許可に同意することができます。
  • ユーザーがデータへのアクセスをアプリケーションに追加または許可すると、そのイベントを監査できるので、Microsoft Entra 管理センター内の監査レポートを表示して、アプリケーションがどのようにディレクトリに追加されたかを判断することができます。

それでもディレクトリ内のユーザーが管理者の承認なしにアプリケーションの登録とアプリケーションへのサインインを実行できないようにするには、これらの機能を無効にするように変更できる 2 つの設定があります。

  • 組織内のユーザーの同意設定を変更するには、「アプリケーションに対するユーザーの同意を構成する」を参照してください。

  • ユーザーが自分のアプリケーションを登録できないようにするには:

    1. Microsoft Entra 管理センターで [ID]>[ユーザー]>[ユーザー設定] に移動します。
    2. [ユーザーはアプリケーションを登録できる][いいえ] に変更します。