アプリケーションを Azure AD に追加する方法と理由How and why applications are added to Azure AD

Azure AD には、2 つの表現のアプリケーションがあります。There are two representations of applications in Azure AD:

  • アプリケーション オブジェクト - 例外はありますが、アプリケーション オブジェクトはアプリケーションの定義と考えることができます。Application objects - Although there are exceptions, application objects can be considered the definition of an application.
  • サービス プリンシパル - アプリケーションのインスタンスと考えることができます。Service principals - Can be considered an instance of an application. 一般的に、サービス プリンシパルはアプリケーション オブジェクトを参照し、1 つのアプリケーション オブジェクトは複数のディレクトリの複数のプリンシパルによって参照されます。Service principals generally reference an application object, and one application object can be referenced by multiple service principals across directories.

アプリケーション オブジェクトの概要とその由来What are application objects and where do they come from?

アプリケーション オブジェクトは、Azure portal の [アプリの登録] エクスペリエンスで管理できます。You can manage application objects in the Azure portal through the App Registrations experience. アプリケーション オブジェクトは、Azure AD に対してアプリケーションについて記述します。アプリケーション オブジェクトはアプリケーションの定義と考えることができます。これにより、サービスは設定に基づいてアプリケーションにトークンを発行する方法を知ることができます。Application objects describe the application to Azure AD and can be considered the definition of the application, allowing the service to know how to issue tokens to the application based on its settings. 他のディレクトリ内のサービス プリンシパルをサポートするマルチテナント アプリケーションであっても、アプリケーション オブジェクトはそのホーム ディレクトリにのみ存在します。The application object will only exist in its home directory, even if it's a multi-tenant application supporting service principals in other directories. アプリケーション オブジェクトには、以下のいずれかが含まれる可能性があります (ここに記載されていない他の情報もあります)。The application object may include any of the following (as well as additional information not mentioned here):

  • 名前、ロゴ、発行元Name, logo, and publisher
  • リダイレクト URIRedirect URIs
  • シークレット (アプリケーションの認証に使用される対称キーまたは非対称キー)Secrets (symmetric and/or asymmetric keys used to authenticate the application)
  • API の依存関係 (OAuth)API dependencies (OAuth)
  • 発行済みの API/リソース/スコープ (OAuth)Published APIs/resources/scopes (OAuth)
  • アプリのロール (RBAC)App roles (RBAC)
  • SSO のメタデータと構成SSO metadata and configuration
  • ユーザー プロビジョニングのメタデータと構成User provisioning metadata and configuration
  • プロキシのメタデータと構成Proxy metadata and configuration

アプリケーション オブジェクトは、以下のような複数の経路で作成できます。Application objects can be created through multiple pathways, including:

  • Azure Portal のアプリケーションの登録Application registrations in the Azure portal
  • Visual Studio を使用して新しいアプリケーションを作成し、Azure AD 認証を使用するように構成するCreating a new application using Visual Studio and configuring it to use Azure AD authentication
  • 管理者がアプリ ギャラリーからアプリケーションを追加するとき (これによってサービス プリンシパルも作成されます)When an admin adds an application from the app gallery (which will also create a service principal)
  • Microsoft Graph API または PowerShell を使用して新しいアプリケーションを作成するUsing the Microsoft Graph API or PowerShell to create a new application
  • Azure でのさまざまな開発者エクスペリエンスや、デベロッパー センターでの API エクスプローラー エクスペリエンスなど、その他多数Many others including various developer experiences in Azure and in API explorer experiences across developer centers

サービス プリンシパルの概要とその由来What are service principals and where do they come from?

サービス プリンシパルは、Azure portal の [エンタープライズ アプリケーション] エクスペリエンスで管理できます。You can manage service principals in the Azure portal through the Enterprise Applications experience. サービス プリンシパルは、実際には Azure AD に接続するアプリケーションを制御するものであり、ディレクトリ内のアプリケーションのインスタンスと考えることができます。Service principals are what govern an application connecting to Azure AD and can be considered the instance of the application in your directory. どのアプリケーションでも、最大で 1 つの ("ホーム" ディレクトリに登録されている) アプリケーション オブジェクトと、アプリケーションが動作する各ディレクトリ内のアプリケーションのインスタンスを表す 1 つ以上のサービス プリンシパル オブジェクトを持つことができます。For any given application, it can have at most one application object (which is registered in a "home" directory) and one or more service principal objects representing instances of the application in every directory in which it acts.

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

  • アプリケーション ID プロパティを使用したアプリケーション オブジェクトへの参照A reference back to an application object through the application ID property
  • ローカル ユーザーとグループ アプリケーション ロールの割り当ての記録Records of local user and group application-role assignments
  • ローカル ユーザーとアプリケーションに許可された管理アクセス許可の記録Records of local user and admin permissions granted to the application
    • 例: 特定のユーザーの電子メールにアクセスするためのアプリケーションに対するアクセス許可For example: permission for the application to access a particular user's email
  • 条件付きアクセス ポリシーを含むローカル ポリシーの記録Records of local policies including Conditional Access policy
  • アプリケーションの代替ローカル設定の記録Records of alternate local settings for an application
    • 要求変換ルールClaims transformation rules
    • 属性マッピング (ユーザーのプロビジョニング)Attribute mappings (User provisioning)
    • ディレクトリ固有のアプリ ロール (アプリケーションがカスタム ロールをサポートする場合)Directory-specific app roles (if the application supports custom roles)
    • ディレクトリ固有の名前またはロゴDirectory-specific name or logo

アプリケーション オブジェクトと同様に、サービス プリンシパルも以下のような複数の経路で作成できます。Like application objects, service principals can also be created through multiple pathways including:

  • ユーザーが Azure AD と統合されたサードパーティ アプリケーションにサインインするときWhen users sign in to a third-party application integrated with Azure AD
    • サインイン中、ユーザーのプロファイルにアプリケーションがアクセスするための許可とその他のアクセス許可を与えるように求められます。During sign-in, users are asked to give permission to the application to access their profile and other permissions. 最初のユーザーがそれに同意した時点で、アプリケーションを表すサービス プリンシパルがディレクトリに追加されます。The first person to give consent causes a service principal that represents the application to be added to the directory.
  • ユーザーが Microsoft 365 などの Microsoft オンライン サービスにサインインするときWhen users sign in to Microsoft online services like Microsoft 365
    • Microsoft 365 をサブスクライブするか、または試用を開始すると、Microsoft 365 に関連するすべての機能を提供するために使用されるさまざまなサービスを表す 1 つまたは複数のサービス プリンシパルがディレクトリに作成されます。When you subscribe to Microsoft 365 or begin a trial, one or more service principals are created in the directory representing the various services that are used to deliver all of the functionality associated with Microsoft 365.
    • SharePoint などの一部の Microsoft 365 サービスは、ワークフローを含むコンポーネント間で安全に通信できるように、実行中にサービス プリンシパルを作成します。Some Microsoft 365 services like SharePoint create service principals on an ongoing basis to allow secure communication between components including workflows.
  • 管理者がアプリ ギャラリーからアプリケーションを追加するとき (これによって基になるアプリケーション オブジェクトも作成されます)When an admin adds an application from the app gallery (this will also create an underlying app object)
  • Azure AD アプリケーション プロキシを使用するアプリケーションを追加するAdd an application to use the Azure AD Application Proxy
  • シングル サインオンのために、SAML またはパスワードのシングル サインオン (SSO) を使用してアプリを接続するConnect an application for single sign on using SAML or password single sign-on (SSO)
  • Microsoft Graph API または PowerShell でプログラムを使用するProgrammatically via the Microsoft Graph API or PowerShell

アプリケーションには、ホーム ディレクトリ内に 1 つのアプリケーション オブジェクトがあり、そのアプリケーション オブジェクトは、アプリケーションが動作する各ディレクトリ (アプリケーションのホーム ディレクトリを含む) 内の 1 つ以上のサービス プリンシパルから参照されます。An application has one application object in its home directory that is referenced by one or more service principals in each of the directories where it operates (including the application's home directory).

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

上の図では、Microsoft はアプリケーションを発行するために使用する 2 つのディレクトリを内部的に保持しています (左側)。In the preceding diagram, Microsoft maintains two directories internally (shown on the left) that it uses to publish applications:

  • 1 つはマイクロソフトのアプリ用 (Microsoft サービス ディレクトリ)One for Microsoft Apps (Microsoft services directory)
  • 1 つは事前に統合されたサードパーティのアプリケーション用 (アプリ ギャラリー ディレクトリ)One for pre-integrated third-party applications (App gallery directory)

Azure AD と統合するアプリケーションのパブリッシャー/ベンダーには、発行ディレクトリが必要です (右側の "Some SaaS Directory")。Application publishers/vendors who integrate with Azure AD are required to have a publishing directory (shown on the right as "Some SaaS Directory").

自分自身を追加するアプリケーション (この図では "App (yours) " と示されている) には、次のアプリケーションが含まれます。Applications that you add yourself (represented as App (yours) in the diagram) include:

  • ユーザーが開発したアプリ (Azure AD と統合)Apps you developed (integrated with Azure AD)
  • シングル サインオン用に接続したアプリApps you connected for single-sign-on
  • Azure AD アプリケーション プロキシを使用して発行したアプリApps you published using the Azure AD application proxy

エラーと例外Notes and exceptions

  • すべてのサービス プリンシパルがアプリケーション オブジェクトを逆参照するわけではありません。Not all service principals point back to an application object. Azure AD が最初に構築された時点では、アプリケーションに提供されるサービスははるかに限定的であり、サービス プリンシパルはアプリケーション ID を確立するのに十分でした。When Azure AD was originally built the services provided to applications were more limited and the service principal was sufficient for establishing an application identity. 元のサービス プリンシパルは、Windows Server Active Directory サービス アカウントとよく似ていました。The original service principal was closer in shape to the Windows Server Active Directory service account. このため、現在でも、先にアプリケーション オブジェクトを作成せずに、Azure AD PowerShell を使用するなど、異なる経路でサービス プリンシパルを作成できます。For this reason, it's still possible to create service principals through different pathways, such as using Azure AD PowerShell, without first creating an application object. Microsoft Graph API では、サービス プリンシパルを作成する前に、アプリケーション オブジェクトが必要です。The Microsoft Graph API requires an application object before creating a service principal.
  • 現在、このような情報の中にはプログラムによって公開されていないものがあります。Not all of the information described above is currently exposed programmatically. 次の情報は UI でのみ使用できます。The following are only available in the UI:
    • 要求変換ルールClaims transformation rules
    • 属性マッピング (ユーザーのプロビジョニング)Attribute mappings (User provisioning)
  • サービス プリンシパル オブジェクトおよびアプリケーション オブジェクトの詳細については、Microsoft Graph API のリファレンス ドキュメントを参照してください。For more detailed information on the service principal and application objects, see the Microsoft Graph API reference documentation:

アプリケーションを Azure AD と統合する理由Why do applications integrate with Azure AD?

アプリケーションは、次のような Azure AD が提供するサービスを利用するために Azure AD に追加されます。Applications are added to Azure AD to leverage one or more of the services it provides including:

  • アプリケーションの認証と承認Application authentication and authorization
  • ユーザーの認証と承認User authentication and authorization
  • フェデレーションまたはパスワードを使用する SSOSSO using federation or password
  • ユーザーのプロビジョニングと同期User provisioning and synchronization
  • ロール ベースのアクセス制御 - ディレクトリを使用して、アプリケーション内でロールに基づく承認チェックを実行するためのアプリケーション ロールを定義します。Role-based access control - Use the directory to define application roles to perform role-based authorization checks in an application
  • OAuth 承認サービス (Microsoft 365 や他の Microsoft アプリケーションによって API/リソースへのアクセスを承認するために使用されます)OAuth authorization services - Used by Microsoft 365 and other Microsoft applications to authorize access to APIs/resources
  • アプリケーションの発行とプロキシ。プライベート ネットワークからインターネットにアプリケーションを発行します。Application publishing and proxy - Publish an application from a private network to the internet
  • ディレクトリ スキーマ拡張機能属性 - サービス プリンシパルとユーザー オブジェクトのスキーマを拡張し、Azure AD で追加データを格納します。Directory schema extension attributes - Extend the schema of service principal and user objects to store additional data in Azure AD

Azure AD インスタンスにアプリケーションを追加する権限のあるユーザーWho has permission to add applications to my Azure AD instance?

グローバル管理者のみが実行できるタスクがいくつかありますが (アプリ ギャラリーからアプリケーションを追加する、アプリケーション プロキシを使用するようにアプリケーションを構成するなど)、既定で、ディレクトリ内のすべてのユーザーは、開発中のアプリケーション オブジェクトを登録する権利を持ち、組織のデータを共有し、アクセス権を付与するアプリケーションについて、同意によって決定することができます。While there are some tasks that only global administrators can do (such as adding applications from the app gallery and configuring an application to use the Application Proxy) by default all users in your directory have rights to register application objects that they are developing and discretion over which applications they share/give access to their organizational data through consent. ディレクトリ内で、アプリケーションにサインインし、同意を許可した最初のユーザーの場合、テナントにサービス プリンシパルが作成されます。それ以外の場合、同意の許可情報は既存のサービス プリンシパルに格納されます。If a person is the first user in your directory to sign in to an application and grant consent, that will create a service principal in your tenant; otherwise, the consent grant information will be stored on the existing service principal.

アプリケーションへの登録と同意をユーザーに許可することは、最初は心配かもいれませんが、以下の点に留意してください。Allowing users to register and consent to applications might initially sound concerning, but keep the following in mind:

  • アプリケーションは、長い間、登録されたりディレクトリに記録されたりしなくても、ユーザー認証に Windows Server Active Directory を利用することができました。Applications have been able to leverage Windows Server Active Directory for user authentication for many years without requiring the application to be registered or recorded in the directory. 現在では、いくつのアプリケーションがどのような目的でディレクトリを使用しているかを正確に認識できるようになっています。Now the organization will have improved visibility to exactly how many applications are using the directory and for what purpose.
  • これらの責任をユーザーに委ねることで、管理主導のアプリケーション登録と公開プロセスの必要がなくなります。Delegating these responsibilities to users negates the need for an admin-driven application registration and publishing process. Active Directory フェデレーション サービス (ADFS) では、開発者に代わって管理者が証明書利用者としてアプリケーションを追加することが必要な場合がありました。With Active Directory Federation Services (ADFS) it was likely that an admin had to add an application as a relying party on behalf of their developers. 今では開発者がセルフ サービスできます。Now developers can self-service.
  • ユーザーがビジネス目的で組織のアカウントを使用してアプリケーションにサインインするのは良いことです。Users signing in to applications using their organization accounts for business purposes is a good thing. 後でユーザーが組織を離れると、自動的に使用していたアプリケーションのアカウントにアクセスできなくなります。If they subsequently leave the organization they will automatically lose access to their account in the application they were using.
  • どのようなデータがどのアプリケーションと共有されていたのかについての記録を残すのは良いことです。Having a record of what data was shared with which application is a good thing. データはかつてより移動性が高くなっており、誰がどのデータをどのアプリケーションと共有したかについての明確な記録があると便利です。Data is more transportable than ever and it's useful to have a clear record of who shared what data with which applications.
  • Azure AD を OAuth に使用する API 所有者は、そのユーザーがアプリケーションに与えることができるアクセス許可および管理者が同意する必要があるアクセス許可を厳密に決定します。API owners who use Azure AD for OAuth decide exactly what permissions users are able to grant to applications and which permissions require an admin to agree to. ユーザーの同意はそのユーザー自身のデータと機能に限定されますが、管理者だけはより大きな範囲とより重要なアクセス許可に同意することができます。Only admins can consent to larger scopes and more significant permissions, while user consent is scoped to the users' own data and capabilities.
  • ユーザーがデータへのアクセスをアプリケーションに追加または許可すると、そのイベントを監査できるので、Azure Portal 内の監査レポートを表示して、アプリケーションがどのようにディレクトリに追加されたかを判断することができます。When a user adds or allows an application to access their data, the event can be audited so you can view the Audit Reports within the Azure portal to determine how an application was added to the directory.

それでもディレクトリ内のユーザーが管理者の承認なしにアプリケーションの登録とアプリケーションへのサインインを実行できないようにするには、これらの機能を無効にするように変更できる 2 つの設定があります。If you still want to prevent users in your directory from registering applications and from signing in to applications without administrator approval, there are two settings that you can change to turn off those capabilities:

  • ユーザーが自分のためにアプリケーションに同意できないようにするには:To prevent users from consenting to applications on their own behalf:

    1. Azure Portal で、エンタープライズ アプリケーションの [ユーザー設定] セクションに移動します。In the Azure portal, go to the User settings section under Enterprise applications.

    2. [ユーザーはアプリが自身の代わりに会社のデータにアクセスすることを許可できます][いいえ] に変更します。Change Users can consent to apps accessing company data on their behalf to No.

      注意

      ユーザーの同意を無効にする場合、ユーザーが新しいアプリケーションを使用する必要があるとき、そのアプリケーションに管理者が同意する必要があります。If you decide to turn off user consent, an admin will be required to consent to any new application a user needs to use.

  • ユーザーが自分のアプリケーションを登録できないようにするには:To prevent users from registering their own applications:

    1. Azure Portal で、Azure Active Directory の [ユーザー設定] セクションに移動します。In the Azure portal, go to the User settings section under Azure Active Directory
    2. [ユーザーはアプリケーションを登録できる][いいえ] に変更します。Change Users can register applications to No.

注意

Microsoft は、ユーザーが自分のためにアプリケーションに登録し、アプリケーションに同意することができる既定の構成を使用しています。Microsoft itself uses the default configuration with users able to register applications and consent to applications on their own behalf.