マルチテナント アプリケーションでの ID 管理Manage Identity in Multitenant Applications

この一連の記事では、Azure AD を認証と ID 管理のために使用する際のマルチテナントのベスト プラクティスについて説明します。This series of articles describes best practices for multitenancy, when using Azure AD for authentication and identity management.

GitHub サンプル コードGitHub Sample code

マルチテナント アプリケーションを構築する場合、最初の課題の 1 つは、すべてのユーザーがテナントに属しているようになるために、ユーザー ID を管理することです。When you're building a multitenant application, one of the first challenges is managing user identities, because now every user belongs to a tenant. 例: For example:

  • ユーザーは、その組織の資格情報でサインインします。Users sign in with their organizational credentials.
  • ユーザーは、その組織のデータへのアクセス権を持つ必要がありますが、他のテナントに属しているデータは必要ありません。Users should have access to their organization's data, but not data that belongs to other tenants.
  • 組織は、アプリケーションにサインアップし、そのメンバーにアプリケーション ロールを割り当てることができます。An organization can sign up for the application, and then assign application roles to its members.

Azure Active Directory (Azure AD) には、これらのシナリオのすべてをサポートするいくつかの優れた機能があります。Azure Active Directory (Azure AD) has some great features that support all of these scenarios.

この一連の記事に付け加えるために、マルチテナント アプリケーションの完全なエンドツーエンド実装を作成しました。To accompany this series of articles, we created a complete end-to-end implementation of a multitenant application. 記事には、アプリケーションの作成プロセスで学習した内容が反映されています。The articles reflect what we learned in the process of building the application. アプリケーションを開始するには、「Run the Surveys application」 (Surveys アプリケーションの実行) を参照してください。To get started with the application, see Run the Surveys application.

はじめにIntroduction

たとえば、クラウドでホストされるエンタープライズ SaaS アプリケーションを作成するとします。Let's say you're writing an enterprise SaaS application to be hosted in the cloud. 当然ながら、アプリケーションにはユーザーがいます。Of course, the application will have users:

ユーザー

ただし、ユーザーは組織に所属しています。But those users belong to organizations:

組織のユーザー

例: Tailspin は、SaaS アプリケーションへのサブスクリプションを販売しています。Example: Tailspin sells subscriptions to its SaaS application. Contoso と Fabrikam がアプリにサインアップします。Contoso and Fabrikam sign up for the app. Alice (alice@contoso) がサインインすると、アプリケーションは Alice が Contoso に属していることを認識します。When Alice (alice@contoso) signs in, the application should know that Alice is part of Contoso.

  • Alice には、Contoso データへのアクセス権が 付与されますAlice should have access to Contoso data.
  • Alice は Fabrikam データのアクセス権を持っているべきではありませんAlice should not have access to Fabrikam data.

このガイダンスでは、マルチテナント アプリケーションで Azure Active Directory (Azure AD) を使用してサインインと認証を処理し、ユーザー ID を管理する方法を説明します。This guidance will show you how to manage user identities in a multitenant application, using Azure Active Directory (Azure AD) to handle sign-in and authentication.

マルチテナントとはWhat is multitenancy?

テナント は、ユーザーのグループです。A tenant is a group of users. SaaS アプリケーションのテナントとは、アプリケーションのサブスクライバーまたは顧客です。In a SaaS application, the tenant is a subscriber or customer of the application. マルチテナント は、複数のテナントがアプリの同じ物理インスタンスを共有するアーキテクチャです。Multitenancy is an architecture where multiple tenants share the same physical instance of the app. テナントは物理リソース (VM や記憶域など) を共有しますが、各テナントにはアプリの論理インスタンスが付与されます。Although tenants share physical resources (such as VMs or storage), each tenant gets its own logical instance of the app.

通常、アプリケーション データは、テナント内のユーザー間で共有されますが、他のテナントとは共有されません。Typically, application data is shared among the users within a tenant, but not with other tenants.

マルチテナント

このアーキテクチャを、各テナントが専用の物理インスタンスを持つシングルテナント アーキテクチャと比較します。Compare this architecture with a single-tenant architecture, where each tenant has a dedicated physical instance. シングルテナント アーキテクチャでは、アプリの新しいインスタンスを起動してテナントを追加します。In a single-tenant architecture, you add tenants by spinning up new instances of the app.

シングル テナント

マルチテナントと水平スケーリングMultitenancy and horizontal scaling

クラウドでスケーリングを達成するには、物理インスタンスを追加する方法が一般的です。To achieve scale in the cloud, it’s common to add more physical instances. これは "水平スケーリング" または "スケーリング アウト" と呼ばれます。たとえば、Web アプリがあるとします。This is known as horizontal scaling or scaling out. Consider a web app. 多くのトラフィックを処理する場合、サーバー VM を追加し、ロード バランサーの背後に配置します。To handle more traffic, you can add more server VMs and put them behind a load balancer. 各 VM では、別物理インスタンスの Web アプリを実行します。Each VM runs a separate physical instance of the web app.

Web サイトの負荷分散

任意の要求を任意のインスタンスにルーティングできます。Any request can be routed to any instance. その結果、システムは 1 つの論理インスタンスとして機能します。Together, the system functions as a single logical instance. ユーザーに影響を与えることなく、VM を増減することができます。You can tear down a VM or spin up a new VM, without affecting users. このアーキテクチャでは、各物理インスタンスがマルチ テナントであり、インスタンスを追加することで拡張できます。In this architecture, each physical instance is multi-tenant, and you scale by adding more instances. 1 つのインスタンスが停止しても、テナントに影響は及びません。If one instance goes down, it should not affect any tenant.

マルチテナント アプリの IDIdentity in a multitenant app

マルチテナント アプリの場合、テナントのコンテキストでユーザーを考慮する必要があります。In a multitenant app, you must consider users in the context of tenants.

認証Authentication

  • ユーザーは、組織の資格情報を使用してアプリにサインインします。Users sign into the app with their organization credentials. ユーザーがアプリの新しいユーザー プロファイルを作成する必要はありません。They don't have to create new user profiles for the app.
  • 同じ組織内のユーザーは、同じテナントに属します。Users within the same organization are part of the same tenant.
  • ユーザーがサインインすると、アプリケーションユーザーが属するテナントを認識します。When a user signs in, the application knows which tenant the user belongs to.

承認Authorization

  • ユーザーのアクション (リソースの表示など) を承認する場合、アプリはユーザーのテナントを考慮する必要があります。When authorizing a user's actions (say, viewing a resource), the app must take into account the user's tenant.
  • ユーザーには、アプリケーション内のロール ("Admin"、"Standard User" など) が割り当てられていることがあります。Users might be assigned roles within the application, such as "Admin" or "Standard User". ロールの割り当ては、SaaS プロバイダーではなく、顧客が管理する必要があります。Role assignments should be managed by the customer, not by the SaaS provider.

例:Example. Contoso の従業員である Alice は、ブラウザーでアプリケーションを開き、[ログイン] ボタンをクリックします。Alice, an employee at Contoso, navigates to the application in her browser and clicks the “Log in” button. ログイン画面にリダイレクトされ、Alice は会社の資格情報 (ユーザー名とパスワード) を入力します。She is redirected to a login screen where she enters her corporate credentials (username and password). この時点で、 alice@contoso.comとしてアプリにログインされます。At this point, she is logged into the app as alice@contoso.com. アプリケーションは、Alice がこのアプリケーションの管理者であることも認識します。The application also knows that Alice is an admin user for this application. Alice は管理者なので、Contoso に属するすべてのリソースの一覧を表示できます。Because she is an admin, she can see a list of all the resources that belong to Contoso. ただし、自分のテナント内でのみ管理者なので、Fabrikam のリソースは表示できません。However, she cannot view Fabrikam's resources, because she is an admin only within her tenant.

このガイドでは、ID 管理のために Azure AD を使用することに注目します。In this guidance, we'll look specifically at using Azure AD for identity management.

  • ここでは、顧客が Azure AD (Office 365 テナントや Dynamics CRM テナントなど) にユーザー プロファイルを保存しているとします。We assume the customer stores their user profiles in Azure AD (including Office365 and Dynamics CRM tenants)
  • オンプレミスの Active Directory (AD) がある顧客は、Azure AD Connect を使用してオンプレミスの AD を Azure AD と同期できます。Customers with on-premise Active Directory (AD) can use Azure AD Connect to sync their on-premise AD with Azure AD.

オンプレミスの AD がある顧客が (会社の IT ポリシーなどの理由で) Azure AD Connect を使用できない場合、SaaS プロバイダーは、Active Directory Federation Services (AD FS) を介して顧客の AD と連携できます。If a customer with on-premise AD cannot use Azure AD Connect (due to corporate IT policy or other reasons), the SaaS provider can federate with the customer's AD through Active Directory Federation Services (AD FS). このオプションについては、「 顧客の AD FS とのフェデレーション」を参照してください。This option is described in Federating with a customer's AD FS.

このガイドでは、データのパーティション分割、テナントごとの構成など、マルチテナントの他の側面について考慮していません。This guidance does not consider other aspects of multitenancy such as data partitioning, per-tenant configuration, and so forth.

次へNext