Azure Service Bus エンティティにアクセスするために Azure Active Directory を使用してアプリケーションを認証および承認するAuthenticate and authorize an application with Azure Active Directory to access Azure Service Bus entities

Azure Service Bus では、Azure Active Directory (Azure AD) を使用して Service Bus エンティティ (キュー、トピック、サブスクリプション、またはフィルター) への要求を承認することがサポートされています。Azure Service Bus supports using Azure Active Directory (Azure AD) to authorize requests to Service Bus entities (queues, topics, subscriptions, or filters). Azure AD では、ロールベースのアクセス制御 (RBAC) を使用して、サービス プリンシパル (ユーザー、グループ、またはアプリケーションのサービス プリンシパルである可能性があります) にアクセス許可を付与します。With Azure AD, you can use role-based access control (RBAC) to grant permissions to a security principal, which may be a user, group, or application service principal. ロールとロールの割り当ての詳細については、各種ロールに関するページを参照してください。To learn more about roles and role assignments, see Understanding the different roles.


セキュリティ プリンシパル (ユーザー、グループ、またはアプリケーション) で Service Bus エンティティへのアクセスが試行された場合、要求が承認される必要があります。When a security principal (a user, group, or application) attempts to access a Service Bus entity, the request must be authorized. Azure AD では、リソースへのアクセスは 2 段階のプロセスです。With Azure AD, access to a resource is a two-step process.

  1. まず、セキュリティ プリンシパルの ID が認証され、OAuth 2.0 トークンが返されます。First, the security principal’s identity is authenticated, and an OAuth 2.0 token is returned. トークンを要求するリソース名は です。The resource name to request a token is
  2. 次に、指定されたリソースへのアクセスを承認するために、トークンが要求の一部として Service Bus サービスに渡されます。Next, the token is passed as part of a request to the Service Bus service to authorize access to the specified resource.

認証の手順により、実行時にアプリケーション要求に OAuth 2.0 アクセス トークンが含まれる必要があります。The authentication step requires that an application request contains an OAuth 2.0 access token at runtime. アプリケーションが Azure VM、仮想マシン スケール セット、または Azure 関数アプリなどの Azure エンティティ内から実行されている場合、マネージド ID を使用してリソースにアクセスできます。If an application is running within an Azure entity such as an Azure VM, a virtual machine scale set, or an Azure Function app, it can use a managed identity to access the resources. マネージド ID によって Service Bus サービスに対して行われる要求を認証する方法については、「Azure Service Bus での Azure リソースのマネージド ID」を参照してください。To learn how to authenticate requests made by a managed identity to Service Bus service, see Authenticate access to Azure Service Bus resources with Azure Active Directory and managed identities for Azure Resources.

承認の手順では、セキュリティ プリンシパルに 1 つ以上の RBAC ロールを割り当てる必要があります。The authorization step requires that one or more RBAC roles be assigned to the security principal. Azure Service Bus には、Service Bus リソースの一連のアクセス許可を含む RBAC ロールが用意されています。Azure Service Bus provides RBAC roles that encompass sets of permissions for Service Bus resources. セキュリティ プリンシパルに割り当てられたロールによって、そのプリンシパルが持つアクセス許可が決定されます。The roles that are assigned to a security principal determine the permissions that the principal will have. Azure Service Bus に RBAC ロールを割り当てる方法の詳細については、「Azure Service Bus 用の組み込み RBAC ロール」を参照してください。To learn more about assigning RBAC roles to Azure Service Bus, see Built-in RBAC roles for Azure Service Bus.

Service Bus に対して要求を行うネイティブ アプリケーションと Web アプリケーションは、Azure AD を使用して承認することもできます。Native applications and web applications that make requests to Service Bus can also authorize with Azure AD. この記事では、アクセス トークンを要求し、それを使用して Service Bus リソースへの要求を承認する方法を示します。This article shows you how to request an access token and use it to authorize requests for Service Bus resources.

アクセス権に対して RBAC ロールを割り当てるAssigning RBAC roles for access rights

Azure Active Directory (Azure AD) では、ロールベースのアクセス制御 (RBAC) を通じて、セキュリティで保護されたリソースへのアクセス権が承認されます。Azure Active Directory (Azure AD) authorizes access rights to secured resources through role-based access control (RBAC). Azure Service Bus では、Service Bus エンティティへのアクセスに使用されるアクセス許可の一般的なセットを含む組み込み RBAC ロールのセットが定義されており、データにアクセスするためのカスタム ロールを定義することもできます。Azure Service Bus defines a set of built-in RBAC roles that encompass common sets of permissions used to access Service Bus entities and you can also define custom roles for accessing the data.

RBAC ロールが Azure AD セキュリティ プリンシパルに割り当てられると、Azure によりそのセキュリティ プリンシパルのリソースへのアクセス権が付与されます。When an RBAC role is assigned to an Azure AD security principal, Azure grants access to those resources for that security principal. アクセスは、サブスクリプションのレベル、リソース グループ、または Service Bus 名前空間にスコープを設定できます。Access can be scoped to the level of subscription, the resource group, or the Service Bus namespace. Azure AD セキュリティ プリンシパルは、Azure リソースのユーザー、グループ、アプリケーション サービス プリンシパル、またはマネージド ID の場合があります。An Azure AD security principal may be a user, a group, an application service principal, or a managed identity for Azure resources.

Azure Service Bus 用の組み込み RBAC ロールBuilt-in RBAC roles for Azure Service Bus

Azure Service Bus の場合、名前空間およびそれに関連するすべてのリソースの Azure Portal および Azure リソース管理 API による管理は、ロールベースのアクセス制御 (RBAC) モデルを使って既に保護されています。For Azure Service Bus, the management of namespaces and all related resources through the Azure portal and the Azure resource management API is already protected using the role-based access control (RBAC) model. Azure では、Service Bus 名前空間へのアクセスを承認するための次の組み込み RBAC ロールが提供されています。Azure provides the below built-in RBAC roles for authorizing access to a Service Bus namespace:

リソースのスコープResource scope

セキュリティ プリンシパルに RBAC ロールを割り当てる前に、セキュリティ プリンシパルに必要なアクセスのスコープを決定します。Before you assign an RBAC role to a security principal, determine the scope of access that the security principal should have. ベスト プラクティスとしては、常にできるだけ狭いスコープのみを付与するのが最善の方法です。Best practices dictate that it's always best to grant only the narrowest possible scope.

次の一覧で、Service Bus リソースへのアクセスのスコープとして指定できるレベルを、最も狭いスコープから順に示します。The following list describes the levels at which you can scope access to Service Bus resources, starting with the narrowest scope:

  • キュートピック、またはサブスクリプション:ロールの割り当ては、特定の Service Bus エンティティに適用されます。Queue, topic, or subscription: Role assignment applies to the specific Service Bus entity. 現在、Azure portal では、サブスクリプション レベルでの Service Bus RBAC ロールへのユーザー/グループ/マネージド ID の割り当てはサポートされていません。Currently, the Azure portal doesn't support assigning users/groups/managed identities to Service Bus RBAC roles at the subscription level.
  • [Service Bus 名前空間] :ロールの割り当ては、名前空間以下とそれに関連付けられているコンシューマー グループに対する Service Bus のトポロジ全体にわたります。Service Bus namespace: Role assignment spans the entire topology of Service Bus under the namespace and to the consumer group associated with it.
  • [リソース グループ] :ロールの割り当ては、リソース グループのすべての Service Bus リソースに適用されます。Resource group: Role assignment applies to all the Service Bus resources under the resource group.
  • サブスクリプション:ロールの割り当ては、サブスクリプションのすべてのリソース グループ内のすべての Service Bus リソースに適用されます。Subscription: Role assignment applies to all the Service Bus resources in all of the resource groups in the subscription.


RBAC ロールの割り当ての反映には最大で 5 分かかる場合があることに留意してください。Keep in mind that RBAC role assignments may take up to five minutes to propagate.

組み込みのロールの定義方法の詳細については、ロール定義に関するページを参照してください。For more information about how built-in roles are defined, see Understand role definitions. カスタム RBAC ロールの作成の詳細については、Azure のロールベースのアクセス制御のためにカスタム ロールを作成する方法に関するページを参照してください。For information about creating custom RBAC roles, see Create custom roles for Azure Role-Based Access Control.

Azure portal を使用した RBAC ロールの割り当てAssign RBAC roles using the Azure portal

RBAC と Azure portal を使用して Azure リソースへのアクセスを管理する方法の詳細については、こちらの記事を参照してください。To learn more on managing access to Azure resources using RBAC and the Azure portal, see this article.

ロールの割り当ての適切なスコープを決定したら、Azure portal でそのリソースに移動します。After you've determined the appropriate scope for a role assignment, navigate to that resource in the Azure portal. リソースの [アクセス制御 (IAM)] 設定を表示し、次の手順に従ってロールの割り当てを管理します。Display the access control (IAM) settings for the resource, and follow these instructions to manage role assignments:


以下に示す手順では、Service Bus 名前空間にロールを割り当てます。The steps described below assigns a role to your Service Bus namespace. 同じ手順に従って、他のサポートされているスコープ (リソース グループ、サブスクリプションなど) にロールを割り当てることができます。You can follow the same steps to assign a role to other supported scopes (resource group, subscription, etc.).

  1. Azure portal で、使用する Service Bus 名前空間に移動します。In the Azure portal, navigate to your Service Bus namespace. 左側のメニューの [アクセス制御 (IAM)] を選択し、名前空間のアクセス制御設定を表示します。Select Access Control (IAM) on the left menu to display access control settings for the namespace. Service Bus 名前空間を作成する必要がある場合は、次の記事の手順に従ってください: Azure Portal を使用して Service Bus 名前空間を作成するIf you need to create a Service Bus namespace, follow instructions from this article: Create a Service Bus Messaging namespace.


  2. [ロールの割り当て] タブを選択して、ロールの割り当ての一覧を表示します。Select the Role assignments tab to see the list of role assignments. ツールバーの [追加] ボタンを選択し、 [ロールの割り当ての追加] を選択します。Select the Add button on the toolbar and then select Add role assignment.

    ツール バーの [追加] ボタン

  3. [ロールの割り当ての追加] ページで、次の手順を実行します。On the Add role assignment page, do the following steps:

    1. 割り当てる Service Bus ロールを選択します。Select the Service Bus role that you want to assign.

    2. ロールの割り当て先となるセキュリティ プリンシパル (ユーザー、グループ、サービス プリンシパル) を検索して見つけます。Search to locate the security principal (user, group, service principal) to which you want to assign the role.

    3. [保存] を選択して、ロールの割り当てを保存します。Select Save to save the role assignment.


    4. ロールの割り当て先となった ID が、そのロールに一覧表示されます。The identity to whom you assigned the role appears listed under that role. たとえば、次の画像は、Azure-users のロールが [Azure Service Bus のデータ所有者] であることを示しています。For example, the following image shows that Azure-users is in the Azure Service Bus Data Owner role.


同様の手順に従って、リソース グループ、またはサブスクリプションにスコープを設定したロールを割り当てることができます。You can follow similar steps to assign a role scoped to a resource group, or a subscription. ロールとそのスコープを定義したら、GitHub のサンプルでこの動作をテストできます。Once you define the role and its scope, you can test this behavior with the samples on GitHub.

アプリケーションからの認証Authenticate from an application

Service Bus で Azure AD を使用する主な利点は、資格情報をコードに格納する必要がなくなることです。A key advantage of using Azure AD with Service Bus is that your credentials no longer need to be stored in your code. 代わりに、Microsoft ID プラットフォームから OAuth 2.0 アクセス トークンを要求することができます。Instead, you can request an OAuth 2.0 access token from Microsoft identity platform. Azure AD によって、アプリケーションを実行しているセキュリティ プリンシパル (ユーザー、グループ、またはサービス プリンシパル) が認証されます。Azure AD authenticates the security principal (a user, a group, or service principal) running the application. 認証が成功すると、Azure AD からアプリケーションにアクセス トークンが返されます。アプリケーションでは、このアクセス トークンを使用して Azure Service Bus への要求を承認できます。If authentication succeeds, Azure AD returns the access token to the application, and the application can then use the access token to authorize requests to Azure Service Bus.

次のセクションでは、Microsoft ID プラットフォーム 2.0 による認証を行うためにネイティブ アプリケーションまたは Web アプリケーションを構成する方法を説明します。Following sections shows you how to configure your native application or web application for authentication with Microsoft identity platform 2.0. Microsoft ID プラットフォーム 2.0 の詳細については、「Microsoft ID プラットフォーム (v2.0) の概要」を参照してください。For more information about Microsoft identity platform 2.0, see Microsoft identity platform (v2.0) overview.

OAuth 2.0 コード付与フローの概要については、「OAuth 2.0 コード付与フローを使用して Azure Active Directory Web アプリケーションへアクセスを承認する」を参照してください。For an overview of the OAuth 2.0 code grant flow, see Authorize access to Azure Active Directory web applications using the OAuth 2.0 code grant flow.

アプリケーションを Azure AD テナントに登録するRegister your application with an Azure AD tenant

Azure AD を使用して Service Bus エンティティを承認する最初の手順は、Azure portal からクライアント アプリケーションを Azure AD テナントに登録することです。The first step in using Azure AD to authorize Service Bus entities is registering your client application with an Azure AD tenant from the Azure portal. クライアント アプリケーションの登録では、アプリケーションに関する情報を AD に提供します。When you register your client application, you supply information about the application to AD. これで Azure AD から、アプリケーションを Azure AD ランタイムと関連付ける際に使用できるクライアント ID (アプリケーション ID とも呼ばれます) が提供されます。Azure AD then provides a client ID (also called an application ID) that you can use to associate your application with Azure AD runtime. クライアント ID の詳細については、「Azure Active Directory のアプリケーション オブジェクトとサービス プリンシパル オブジェクト」を参照してください。To learn more about the client ID, see Application and service principal objects in Azure Active Directory.

次の画像は、Web アプリケーションを登録するための手順を示します。The following images show steps for registering a web application:



アプリケーションをネイティブ アプリケーションとして登録する場合は、リダイレクト URI 用に任意の有効な URI を指定できます。If you register your application as a native application, you can specify any valid URI for the Redirect URI. ネイティブ アプリケーションの場合、この値が実際の URL である必要はありません。For native applications, this value does not have to be a real URL. Web アプリケーションの場合、リダイレクト URI はトークンが提供される URL を指定するため、有効な URI である必要があります。For web applications, the redirect URI must be a valid URI, because it specifies the URL to which tokens are provided.

アプリケーションを登録すると、 [設定][アプリケーション (クライアント) ID] が表示されます。After you've registered your application, you'll see the Application (client) ID under Settings:

登録されたアプリケーションのアプリケーション ID

Azure AD へのアプリケーションの登録について詳しくは、「Azure Active Directory とアプリケーションの統合」を参照してください。For more information about registering an application with Azure AD, see Integrating applications with Azure Active Directory.


TenantIdApplicationId をメモしておきます。Make note of the TenantId and the ApplicationId. アプリケーションを実行するためにこれらの値が必要になります。You will need these values to run the application.

クライアント シークレットの作成Create a client secret

アプリケーションでは、トークンを要求するときに ID を証明するためにクライアント シークレットが必要です。The application needs a client secret to prove its identity when requesting a token. クライアント シークレットを追加するには、次の手順を行います。To add the client secret, follow these steps.

  1. Azure portal でアプリの登録に移動します (そのページにまだアクセスしていない場合)。Navigate to your app registration in the Azure portal if you aren't already on the page.

  2. 左側のメニューの [証明書とシークレット] を選択します。Select Certificates & secrets on the left menu.

  3. [クライアント シークレット] で、 [新しいクライアント シークレット] を選択して新しいシークレットを作成します。Under Client secrets, select New client secret to create a new secret.

    [新しいクライアント シークレット] - ボタン

  4. シークレットの説明を入力し、必要な有効期限の間隔を選んで、 [追加] を選択します。Provide a description for the secret, and choose the wanted expiration interval, and then select Add.

    クライアント シークレットの追加ページ

  5. すぐに新しいシークレットの値を安全な場所にコピーします。Immediately copy the value of the new secret to a secure location. 完全な値は 1 回だけ表示されます。The fill value is displayed to you only once.

    クライアント シークレット

Service Bus API のアクセス許可Permissions for the Service Bus API

アプリケーションがコンソール アプリケーションである場合は、ネイティブ アプリケーションを登録し、Microsoft.ServiceBus に対する API アクセス許可を必要なアクセス許可セットに追加する必要があります。If your application is a console application, you must register a native application and add API permissions for Microsoft.ServiceBus to the required permissions set. また、ネイティブ アプリケーションには、識別子として機能する、Azure AD のリダイレクト URI も必要です。この URI はネットワーク宛先である必要はありません。Native applications also need a redirect-URI in Azure AD, which serves as an identifier; the URI does not need to be a network destination. この例では、サンプル コードが を既に使っているため、この URI を使います。Use for this example, because the sample code already uses that URI.

トークン取得のためのクライアント ライブラリClient libraries for token acquisition

アプリケーションを登録し、Azure Service Bus でデータを送受信するためのアクセス許可をこれに付与したら、セキュリティ プリンシパルを認証して OAuth 2.0 トークンを取得するためのコードをアプリケーションに追加できます。Once you've registered your application and granted it permissions to send/receive data in Azure Service Bus, you can add code to your application to authenticate a security principal and acquire OAuth 2.0 token. 認証してトークンを取得するには、Microsoft ID プラットフォームの認証ライブラリか、OpenID または Connect 1.0 をサポートする別のオープンソース ライブラリのいずれかを使用することができます。To authenticate and acquire the token, you can use either one of the Microsoft identity platform authentication libraries or another open-source library that supports OpenID or Connect 1.0. その後、アプリケーションでアクセス トークンを使用して、Azure Service Bus に対する要求を承認することができます。Your application can then use the access token to authorize a request against Azure Service Bus.

トークンの取得がサポートされるシナリオの一覧は、Microsoft Authentication Library (MSAL) for .NET GitHub リポジトリのシナリオのセクションを参照してください。For a list of scenarios for which acquiring tokens is supported, see the Scenarios section of the Microsoft Authentication Library (MSAL) for .NET GitHub repository.

GitHub 上のサンプルSample on GitHub

GitHub の次のサンプルを参照してください: Service Bus のロールベースのアクセス制御See the following sample on GitHub: Role-base access control for Service Bus.

[Interactive User Login](対話型のユーザー ログイン) オプションではなく、 [Client Secret Login](クライアント シークレット ログイン) オプションを使用します。Use the Client Secret Login option, not the Interactive User Login option. クライアント シークレット オプションを使用すると、ポップアップ ウィンドウが表示されません。When you use the client secret option, you don't see a pop-up window. アプリケーションでは、認証にテナント ID とアプリ ID が利用されます。The application utilizes the tenant ID and app ID for authentication.

サンプルを実行するRun the sample

サンプルを実行する前に、app.config ファイルを編集し、シナリオに応じて、次の値を設定します。Before you can run the sample, edit the app.config file and, depending on your scenario, set the following values:

  • tenantId:TenantId の値に設定します。tenantId: Set to TenantId value.
  • clientId:ApplicationId の値に設定します。clientId: Set to ApplicationId value.
  • clientSecret:クライアント シークレットを使ってサインオンする場合は、Azure AD で作成します。clientSecret: If you want to sign in using the client secret, create it in Azure AD. また、ネイティブ アプリの代わりに Web アプリまたは API を使います。Also, use a web app or API instead of a native app. また、前に作成した名前空間の [アクセス制御 (IAM)] にアプリを追加します。Also, add the app under Access Control (IAM) in the namespace you previously created.
  • serviceBusNamespaceFQDN:新しく作成した Service Bus 名前空間の完全な DNS 名に設定します (例:。serviceBusNamespaceFQDN: Set to the full DNS name of your newly created Service Bus namespace; for example,
  • queueName:作成したキューの名前に設定します。queueName: Set to the name of the queue you created.
  • 前の手順においてアプリで指定したリダイレクト URI です。The redirect URI you specified in your app in the previous steps.

コンソール アプリケーションを実行すると、シナリオを選択するように求められます。When you run the console application, you are prompted to select a scenario. 数値を入力し、Enter キーを押して、 [Interactive User Login](対話型のユーザー ログイン) を選択します。Select Interactive User Login by typing its number and pressing ENTER. アプリケーションはログイン ウィンドウを表示し、Service Bus へのアクセスの同意を求めた後、サービスを使ってログイン ID を用いた送信/受信シナリオを実行します。The application displays a login window, asks for your consent to access Service Bus, and then uses the service to run through the send/receive scenario using the login identity.

次の手順Next steps

Service Bus メッセージングの詳細については、次のトピックをご覧ください。To learn more about Service Bus messaging, see the following topics.