Power BI 埋め込みを使用してスケーラブルなマルチテナントアプリケーションを開発する

[アーティクル]
11/23/2023

この記事では、最高レベルのスケーラビリティ、パフォーマンス、セキュリティを実現しながら、Power BI コンテンツを埋め込むマルチテナントアプリケーションを開発する方法について説明します。 "サービスプリンシパルプロファイル" を使用してアプリケーションを設計および実装することで、対象ユーザーである 100,000 人以上のユーザーにレポートを配信できる、数万人の顧客テナントで構成されたマルチテナントソリューションを作成して管理できます。

"サービスプリンシパルプロファイル" は、Power BI で組織のコンテンツをより簡単に管理し、容量をより効率的に使用できるようにする機能です。ただし、サービスプリンシパルプロファイルを使用すると、アプリケーションの設計が複雑になることがあります。したがって、大きな規模を達成する必要がある場合にだけ使用する必要があります。サービスプリンシパルプロファイルは、多数のワークスペースがあり、アプリケーションユーザーが 1,000 人を超えている場合に使用することをお勧めします。

注意

サービスプリンシパルプロファイルを使用する価値は、スケーリングの必要性が高まるにつれて、また、最高レベルのセキュリティとテナントの分離を実現する必要性に応じて増加します。

Power BI の埋め込みは、"組織向け埋め込み" と "顧客向け埋め込み" という 2 つの異なる埋め込みシナリオを使用して実現できます。

組織向け埋め込みシナリオは、アプリケーションの対象ユーザーが "内部" ユーザーで構成されている場合に適用されます。内部ユーザーは組織のアカウントを持ち、Microsoft Entra ID (旧称 Azure Active Directory) で認証する必要があります。このシナリオでは、Power BI はサービスとしてのソフトウェア (SaaS) です。これは "ユーザー所有データ" と呼ばれることもあります。

顧客向け埋め込みシナリオは、アプリケーションの対象ユーザーが "外部" ユーザーで構成されている場合に適用されます。そのアプリケーションでユーザーの認証を行います。 Power BI コンテンツにアクセスするために、このアプリケーションは埋め込み ID (Microsoft Entra サービスプリンシパルまたはマスターユーザーアカウント) に依存して、Microsoft Entra で認証します。このシナリオでは、Power BI はサービスとしてのプラットフォーム (PaaS) です。これは "アプリ所有データ" と呼ばれることもあります。

注意

重要なこととして、サービスプリンシパルプロファイル機能は "顧客向け埋め込み" シナリオで使用するために設計されたものであることを理解しておいてください。それは、このシナリオにより、ISV とエンタープライズ組織が多数のユーザーと多数の顧客テナントに対して、より大規模に埋め込むことができるからです。

マルチテナントアプリケーション開発

Microsoft Entra に慣れている場合は、テナントという単語が Microsoft Entra テナントを連想させるかも知れません。ただし、Power BI コンテンツを埋め込むマルチテナントソリューションを構築するコンテキストでは、テナントの概念が異なります。このコンテキストでは、Power BI コンテンツを埋め込む各顧客に代わって、"顧客向け埋め込み" シナリオを使用してアプリケーションで "顧客テナント"が作成されます。通常は、1 つの Power BI ワークスペースを作成して各顧客テナントをプロビジョニングします。

スケーラブルなマルチテナントソリューションを作成するには、新しい顧客テナントの作成を自動化できる必要があります。新しい顧客テナントをプロビジョニングするには、通常、Power BI REST API を使用して新しい Power BI ワークスペースを作成するコードを記述することや、Power BI Desktop (.pbix) ファイルをインポートすることによってセマンティックモデル (旧称: データセット) を作成すること、また、データソースパラメーターの更新、データソース資格情報の設定、スケジュールされたセマンティックモデル更新の設定を行うことが必要です。次の図は、レポートやセマンティックモデルなどの Power BI 項目をワークスペースに追加して、顧客テナントを設定する方法を示しています。

3 つのテナントのセットアップを示す図。各テナントに独自のデータソースとワークスペースがあります。

"顧客向け埋め込み" シナリオを使用するアプリケーションを開発する場合は、Power BI REST API 呼び出しを行うために埋め込み ID を使用できます。これは、マスターユーザーアカウントまたはサービスプリンシパルのいずれかです。運用アプリケーションにはサービスプリンシパルを使用することをお勧めします。これは最高のセキュリティを提供します。このため、Microsoft Entra が推奨するアプローチです。また、より優れた自動化とスケールをサポートし、管理オーバーヘッドが軽減されます。ただし、セットアップと管理には Power BI 管理者権限が必要です。

サービスプリンシパルを使用すると、ユーザーが多要素認証 (MFA) を使用してサインインする必要がある環境での認証エラーなど、マスターユーザーアカウントに関連する一般的な問題を回避できます。サービスプリンシパルを使用することは、"顧客向け埋め込み" シナリオが、SaaS の発想ではなく PaaS の発想を使用して Power BI コンテンツを埋め込むことに基づいているという考え方にも一致します。

1,000 ワークスペースの制限

"顧客向け埋め込み" シナリオを実装するマルチテナント環境を設計する場合は、埋め込み ID に 1,000 個を超えるワークスペースへのアクセスを許可できないことを考慮してください。 Power BI サービスでは、REST API 呼び出しを行うときのパフォーマンス向上のために、この制限が適用されます。この制限の理由は、Power BI で各 ID のセキュリティ関連メタデータがどのように維持されるかに関連しています。

Power BI では、ID でアクセスできるワークスペースとワークスペース項目を追跡するためにメタデータが使用されます。実際には、Power BI では、認証サブシステム内の ID ごとに個別のアクセス制御リスト (ACL) を保持する必要があります。 ID で REST API 呼び出しを行ってワークスペースにアクセスする場合、それが承認されていることを確認するために、Power BI によって ID の ACL に対してセキュリティチェックが行われます。ターゲットワークスペースが ACL 内にあるかどうかを判断するのにかかる時間は、ワークスペースの数が増えるにつれて指数関数的に増加します。

注意

Power BI では、1,000 ワークスペースという制限がコードを通して適用されることはありません。そうしようと思えば、1,000 個を超えるワークスペースに埋め込み ID を追加しても、REST API 呼び出しは正常に実行されます。ただし、アプリケーションは "サポート対象外" の状態に移行するため、Microsoft サポートに支援を求めようとした場合に影響を受ける可能性があります。

2 つのマルチテナントアプリケーションがそれぞれ 1 つのサービスプリンシパルを使用するように設定されているシナリオについて考えてみます。ここで、最初のアプリケーションで 990 個のワークスペースを作成し、2 番目のアプリケーションで 1,010 個のワークスペースを作成したとします。サポートの観点から見ると、最初のアプリケーションはサポート対象の境界内にありますが、2 番目のアプリケーションはそうではありません。

次に、これら 2 つのアプリケーションを純粋にパフォーマンスの観点から比較してみましょう。それほど大きな違いはありません。なぜなら、両方のサービスプリンシパルの ACL で、パフォーマンスがある程度低下するポイントまで ACL のメタデータの増加が許可されているためです。

重要な観察事項は次のとおりです。サービスプリンシパルによって作成されたワークスペースの数は、パフォーマンスとスケーラビリティに直接影響します。 100 個のワークスペースのメンバーであるサービスプリンシパルの場合、1,000 個のワークスペースのメンバーであるサービスプリンシパルよりも高速に REST API 呼び出しが実行されます。同様に、10 個のワークスペースのみのメンバーであるサービスプリンシパルの場合、100 個のワークスペースのメンバーであるサービスプリンシパルよりも高速に REST API 呼び出しが実行されます。

重要

パフォーマンスとスケーラビリティの観点からは、サービスプリンシパルがメンバーであるワークスペースの最適な数は "1 つだけ" です。

セマンティックモデルとデータソース資格情報の分離を管理する

マルチテナントアプリケーションを設計する際のもう 1 つの重要な側面は、顧客のテナントを分離することです。ある顧客テナントのユーザーに、別の顧客テナントに属するデータが表示されないことが重要です。したがって、セマンティックモデルの所有権とデータソース資格情報を管理する方法を理解する必要があります。

セマンティックモデルの所有権

各 Power BI セマンティックモデルには 1 人の所有者が存在し、それはユーザーアカウントまたはサービスプリンシパルにすることができます。スケジュールされた更新を設定し、セマンティックモデルパラメーターを設定するには、セマンティックモデルの所有権が必要です。

ヒント

Power BI サービスでは、セマンティックモデルの設定を開くことで、セマンティックモデルの所有者を特定できます。

必要に応じて、セマンティックモデルの所有権を別のユーザーアカウントまたはサービスプリンシパルに譲渡できます。これは Power BI サービスで、または REST API の TakeOver 操作を使用して行うことができます。サービスプリンシパルを使用して新しいセマンティックモデルを作成するために Power BI Desktop ファイルをインポートすると、サービスプリンシパルがセマンティックモデルの所有者として自動的に設定されます。

データソース資格情報

セマンティックモデルをその基になるデータソースに接続するには、セマンティックモデルの所有者がデータソースの資格情報を設定する必要があります。データソース資格情報は、Power BI によって暗号化され、キャッシュされます。その時点から、Power BI でそれらの資格情報を使用して、データを更新するとき (インポートのストレージテーブルの場合)、またはパススルークエリを実行するとき (DirectQuery ストレージテーブルの場合) に、基になるデータソースで認証が行われます。

新しい顧客テナントをプロビジョニングするときに、一般的な設計パターンを適用することをお勧めします。サービスプリンシパルの ID を使用して、一連の REST API 呼び出しを実行できます。

新しいワークスペースを作成します。
新しいワークスペースを専用の容量に関連付けます。
セマンティックモデル作成するために、Power BI Desktop ファイルをインポートします。
そのセマンティックモデルのセマンティックモデルソース資格情報を設定します。

これらの REST API 呼び出しが完了すると、サービスプリンシパルは新しいワークスペースの管理者になり、セマンティックモデルとデータソース資格情報の所有者になります。

重要

セマンティックモデルのデータソース資格情報はワークスペースレベルにスコープが設定されているという一般的な誤解があります。そうではありません。データソース資格情報はサービスプリンシパル (またはユーザーアカウント) にスコープが設定され、そのスコープは Microsoft Entra テナント内のすべての Power BI ワークスペースにまで拡張されます。

サービスプリンシパルを使用すると、次の図に示すように、顧客テナント間の異なるワークスペース内のセマンティックモデルによって共有されるデータソース資格情報を作成できます。

2 つのテナントのセットアップを示す図。各テナントは、同じデータソース資格情報を共有しています。

データソース資格情報が、異なる顧客テナントに属するセマンティックモデルによって共有されている場合、顧客テナントは完全には分離されません。

サービスプリンシパルプロファイルより前の設計戦略

サービスプリンシパルプロファイル機能を使用できるようになる前の設計戦略を理解することは、この機能の必要性を理解するのに役立ちます。そうなる前は、開発者は次の 3 つの設計戦略のいずれかを使用してマルチテナントアプリケーションを構築していました。

単一サービスプリンシパル
サービスプリンシパルプール
ワークスペースごとに 1 つのサービスプリンシパル

これらの設計戦略には、それぞれ長所と短所があります。

単一サービスプリンシパルの設計戦略では、Microsoft Entra アプリの登録を 1 回限り作成する必要があります。そのため、Microsoft Entra アプリの登録を追加作成する必要がなく、他の 2 つの設計戦略よりも管理オーバーヘッドが少なくなります。また、この戦略は、REST API 呼び出しを行うときにサービスプリンシパル間で呼び出しコンテキストを切り替える追加のコードを記述する必要がないため、最も簡単に設定できます。ただし、この設計戦略の問題点は、スケーリングされないということです。サポートされるのは、最大 1,000 個のワークスペースまで拡張できる 1 個のマルチテナント環境のみです。また、サービスプリンシパルに多数のワークスペースへのアクセスが許可されるため、パフォーマンスは確実に低下します。単一のサービスプリンシパルが、すべての顧客テナントのすべてのセマンティックモデルとすべてのデータ資格情報の所有者になるため、顧客テナントの分離にも問題があります。

サービスプリンシパルプールの設計戦略は、1,000 ワークスペースという制限を回避するために一般的に使用されます。これにより、適切な数のサービスプリンシパルをプールに追加することで、アプリケーションで任意の数のワークスペースにスケーリングできます。たとえば、5 つのサービスプリンシパルからなるプールを使用すると、最大 5,000 個までワークスペースをスケールアップでき、80 個のサービスプリンシパルからなるプールを使用すると、最大 80,000 個までワークスペースをスケールアップできる、というようになります。ただし、この戦略は多数のワークスペースへのスケーリングが可能ですが、いくつかの欠点があります。最初に、REST API 呼び出しを行うときにサービスプリンシパル間でコンテキスト切り替えができるように、追加のコードを記述し、メタデータを格納する必要があります。次に、プール内のサービスプリンシパルの数を増やす必要がある場合は常に Microsoft Entra アプリの登録を作成する必要があるため、より多くの管理作業が必要になります。

さらに、サービスプリンシパルプールの戦略では、サービスプリンシパルを数百個のワークスペースのメンバーにできるため、パフォーマンスのための最適化はされていません。また、サービスプリンシパルが顧客テナント間で共有されるセマンティックモデルとデータ資格情報の所有者になる可能性があるため、顧客テナント分離の観点から見て理想的ではありません。

ワークスペースごとに 1 つのサービスプリンシパルという設計戦略では、顧客テナントごとにサービスプリンシパルを作成する必要があります。理論的な観点からは、これは最適なソリューションを提供する戦略です。REST API 呼び出しのパフォーマンスを最適化しながら、ワークスペースレベルでセマンティックモデルとデータソース資格情報を真に分離できるからです。ただし、理論的に最も効果的なものが必ずしも実際に最適とは限りません。これは、顧客テナントごとにサービスプリンシパルを作成するという要件は、多くの組織にとって実用的ではないからです。これは、一部の組織に正式な承認プロセスが存在するか、Microsoft Entra アプリの登録を作成するために過剰な管理を伴うためです。これらの理由により、カスタムアプリケーションに対して、Microsoft Entra アプリ登録の作成に必要な権限をオンデマンドで、かつソリューションに必要な自動化された方法で付与できなくなる可能性があります。

あまり一般的なシナリオではありませんが、カスタムアプリケーションに適切なアクセス許可が付与されている場合は、Microsoft Graph API を使用して、必要に応じて Microsoft Entra アプリの登録を作成できます。ただし、カスタムアプリケーションは、Microsoft Entra アプリの登録ごとに何らかの方法で認証資格情報を追跡する必要があるため、開発とデプロイが複雑になることがよくあります。また、個々のサービスプリンシパルのアクセストークンを認証して取得する必要がある場合は常に、これらの資格情報へのアクセス権を取得する必要があります。

サービスプリンシパルプロファイル

サービスプリンシパルプロファイルは、Power BI で組織のコンテンツをより簡単に管理し、容量をより効率的に使用できるようにするために設計された機能です。開発者の労力とオーバーヘッドを最小限に抑えて 3 つの特定の課題に対処するのに役立ちます。次のような課題があります。

多数のワークスペースにスケーリングする。
REST API 呼び出しのパフォーマンスを最適化する。
顧客テナントレベルでセマンティックモデルとデータソース資格情報を分離する。

サービスプリンシパルプロファイルを使用してマルチテナントアプリケーションを設計する場合、関連する弱点を回避しながら、(前のセクションで説明した) 3 つの設計戦略の長所を活用できます。

サービスプリンシパルプロファイルは、Power BI のコンテキスト内で作成されるローカルアカウントです。サービスプリンシパルで Profiles REST API 操作を使用して、新しいサービスプリンシパルプロファイルを作成できます。サービスプリンシパルを使用すると、次の図に示すように、カスタムアプリケーション用の独自のサービスプリンシパルプロファイルのセットを作成し、管理できます。

Power BI で 3 つのサービスプリンシパルプロファイルを作成するサービスプリンシパルを示す図。

サービスプリンシパルと、それによって作成されたサービスプリンシパルプロファイルの間には、常に親子関係があります。スタンドアロンエンティティとしてサービスプリンシパルプロファイルを作成することはできません。代わりに、特定のサービスプリンシパルを使用してサービスプリンシパルプロファイルを作成し、そのサービスプリンシパルがプロファイルの親として機能します。さらに、サービスプリンシパルプロファイルは、ユーザーアカウントやその他のサービスプリンシパルには表示されません。サービスプリンシパルプロファイルは、それを作成したサービスプリンシパルでのみ表示および使用できます。

サービスプリンシパルプロファイルが Microsoft Entra に認識されない

サービスプリンシパル自体とその基になる Microsoft Entra アプリの登録は Microsoft Entra には認識されていますが、サービスプリンシパルプロファイルについては Microsoft Entra ID は何も認識していません。これは、サービスプリンシパルプロファイルは Power BI によって作成され、Power BI のセキュリティと承認を制御する Power BI サービスサブシステムにのみ存在するためです。

サービスプリンシパルプロファイルが Microsoft Entra ID に認識されないという事実には、利点と欠点の両方があります。主な利点は、"顧客向け埋め込み" シナリオのアプリケーションでサービスプリンシパルプロファイルを作成するために、特別な Microsoft Entra アクセス許可が不要な点です。これはまた、アプリケーションで Microsoft Entra とは別のローカル ID のセットを作成して管理できることを意味します。

ただし、欠点もあります。サービスプリンシパルプロファイルは Microsoft Entra では認識されないため、Microsoft Entra グループにサービスプリンシパルプロファイルを追加して、ワークスペースへのアクセスを暗黙的に許可することはできません。また、Azure SQL Database や Azure Synapse Analytics などの外部データソースは、データベースに接続するときにサービスプリンシパルプロファイルを ID として認識できません。そのため、各顧客テナントに固有の認証資格情報がある個別のサービスプリンシパルを使用してこれらのデータソースに接続する必要がある場合は、ワークスペースごとに 1 つのサービスプリンシパルという設計戦略 (各顧客テナントのサービスプリンシパルを作成する) の方が適している可能性があります。

最上級のセキュリティプリンシパルであるサービスプリンシパルプロファイル

サービスプリンシパルプロファイルは Microsoft Entra では認識されませんが、Power BI ではそれらが最上級のセキュリティプリンシパルとして認識されます。ユーザーアカウントやサービスプリンシパルと同様に、ワークスペースロールにサービスプリンシパルプロファイルを (管理者またはメンバーとして) 追加できます。セマンティックモデルの所有者とデータソース資格情報の所有者にすることもできます。このような理由から、新しい顧客テナントごとに新しいサービスプリンシパルプロファイルを作成することをお勧めします。

複数の顧客テナントを示す図。それぞれに独自のサービスプリンシパルプロファイルがあります。

ヒント

サービスプリンシパルプロファイルを使用して "顧客向け埋め込み" シナリオのアプリケーションを開発する場合は、1 つの Microsoft Entra アプリ登録を作成するだけで、アプリケーションに 1 つのサービスプリンシパルを提供できます。このアプローチでは、アプリケーションを運用環境にデプロイした後、継続的に追加の Microsoft Entra アプリ登録を作成する必要がある他のマルチテナント設計戦略と比較して、管理オーバーヘッドが大幅に削減されます。

REST API 呼び出しをサービスプリンシパルプロファイルとして実行

アプリケーションでサービスプリンシパルプロファイルの ID を使用して、REST API 呼び出しを実行できます。つまり、一連の REST API 呼び出しを実行して、新しい顧客テナントをプロビジョニングし、設定できます。

サービスプリンシパルプロファイルで新しいワークスペースが作成されると、Power BI によってそのプロファイルがワークスペース管理者として自動的に追加されます。
サービスプリンシパルプロファイルで Power BI Desktop ファイルをインポートしてセマンティックモデルを作成すると、Power BI によってそのプロファイルがセマンティックモデルの所有者として設定されます。
サービスプリンシパルプロファイルでデータソース資格情報を設定すると、Power BI によってそのプロファイルがデータソース資格情報の所有者として設定されます。

サービスプリンシパルには Power BI 内の ID があり、それはプロファイルの ID とは別の ID であることを理解しておくことが重要です。これにより、開発者としての選択肢が提供されます。 REST API 呼び出しは、サービスプリンシパルプロファイルの ID を使用して実行できます。または、プロファイルなしで REST API 呼び出しを実行することもできます。その場合、親サービスプリンシパルの ID が使用されます。

サービスプリンシパルプロファイルを作成、表示、または削除する場合は、REST API 呼び出しを親サービスプリンシパルとして実行することをお勧めします。他のすべての REST API 呼び出しの実行には、サービスプリンシパルプロファイルを使用する必要があります。これらの他の呼び出しを使用して、ワークスペースの作成、Power BI Desktop ファイルのインポート、セマンティックモデルパラメーターの更新、データソース資格情報の設定を行うことができます。また、ワークスペース項目のメタデータを取得し、埋め込みトークンを生成することもできます。

例として、Contoso という名前の顧客用に顧客テナントを設定する必要がある場合を考えてみましょう。最初の手順では、REST API 呼び出しを行って、表示名を Contoso に設定したサービスプリンシパルプロファイルを作成します。この呼び出しは、サービスプリンシパルの ID を使用して行われます。残りすべてのセットアップ手順では、サービスプリンシパルプロファイルを使用して以下のタスクを実行します。

ワークスペースを作成します。
ワークスペースを容量に関連付けます。
Power BI Desktop ファイルをインポートします。
セマンティックモデルのパラメーターを設定します。
データソースの資格情報を設定します。
スケジュールされたデータ更新を設定します。

ワークスペースとそのコンテンツへのアクセスは、顧客テナントの作成に使用されたサービスプリンシパルプロファイルの ID を使用して行う必要があります。このことを理解しておくことが重要です。また、親サービスプリンシパルはワークスペースまたはそのコンテンツにアクセスする必要がないことを理解することも重要です。

ヒント

注意: REST API 呼び出しを行うときは、サービスプリンシパルを使用してサービスプリンシパルプロファイルを作成および管理し、サービスプリンシパルプロファイルを使用して Power BI コンテンツの作成、設定、アクセスを行います。

Profiles REST API 操作を使用する

Profiles REST API 操作グループは、サービスプリンシパルプロファイルを作成および管理する操作で構成されています。

Create Profile
Delete Profile
Get Profile
Get Profiles
Update Profile

サービスプリンシパルプロファイルを作成する

サービスプリンシパルプロファイルを作成するには、Create Profile REST API 操作を使用します。新しいテナントの表示名を指定するには、要求本文で displayName プロパティを設定する必要があります。この値は、サービスプリンシパルが所有するすべてのプロファイルで一意である必要があります。その表示名を持つ別のプロファイルがサービスプリンシパルに既に存在する場合、呼び出しは失敗します。

呼び出しが成功すると、id プロパティが返されます。これはプロファイルを表す GUID です。サービスプリンシパルプロファイルを使用するアプリケーションを開発する場合は、プロファイルの表示名とその ID 値をカスタムデータベースに格納することをお勧めします。そうすることで、アプリケーションで ID を簡単に取得できます。

Power BI .NET SDK を使用してプログラミングする場合は、新しいプロファイルを表す ServicePrincipalProfile オブジェクトを返す Profiles.CreateProfile メソッドを使用できます。これにより、id プロパティ値を簡単に特定できます。

サービスプリンシパルプロファイルを作成し、ワークスペースへのアクセスを許可する例を次に示します。

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

// Retrieve the ID of the new profile
Guid profileId = profile.Id;

// Grant workspace access
var groupUser = new GroupUser {
    GroupUserAccessRight = "Admin",
    PrincipalType = "App",
    Identifier = ServicePrincipalId,
    Profile = new ServicePrincipalProfile {
        Id = profileId
    }
};

pbiClient.Groups.AddGroupUser(workspaceId, groupUser);

Power BI サービスのワークスペースの [アクセス] ペインで、セキュリティプリンシパルを含め、どの ID にアクセス許可があるかを確認できます。

サービスプリンシパルプロファイルを削除する

サービスプリンシパルプロファイルを削除するには、Delete Profile REST API 操作を使用します。この操作は、親サービスプリンシパルによってのみ呼び出すことができます。

Power BI .NET SDK を使用してプログラミングする場合は、Profiles.DeleteProfile メソッドを使用できます。

すべてのサービスプリンシパルプロファイルを取得する

呼び出し元のサービスプリンシパルに属するサービスプリンシパルプロファイルの一覧を取得するには、Get Profiles REST API 操作を使用します。この操作により、各サービスプリンシパルプロファイルの id および displayName プロパティを含む JSON ペイロードが返されます。

Power BI .NET SDK を使用してプログラミングする場合は、Profiles.GetProfiles メソッドを使用できます。

サービスプリンシパルプロファイルを使用して REST API 呼び出しを実行する

サービスプリンシパルプロファイルを使用して REST API 呼び出しを行う場合、2 つの要件があります。

Authorization ヘッダーで親サービスプリンシパルのアクセストークンを渡す必要があります。
サービスプリンシパルプロファイルの ID を値に持つ X-PowerBI-profile-id という名前のヘッダーを含める必要があります。

Power BI .NET SDK を使用している場合は、サービスプリンシパルプロファイルの ID を渡すことによって、X-PowerBI-profile-id ヘッダーの値を明示的に設定できます。

// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);

// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);

// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();

上記の例に示したように、X-PowerBI-profile-id ヘッダーを PowerBIClient オブジェクトに追加すると、Groups.GetGroups などのメソッドを簡単に呼び出して、それらがサービスプリンシパルプロファイルを使用して実行されるようにすることができます。

PowerBIClient オブジェクトの X-PowerBI-profile-id ヘッダーを設定するよりも便利な方法があります。プロファイルの ID をコンストラクターに渡すことによって、オブジェクトを初期化できます。

// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";

var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);

マルチテナントアプリケーションをプログラミングするときは、親サービスプリンシパルとしての呼び出しの実行とサービスプリンシパルプロファイルとしての呼び出しの実行を切り替える必要がある可能性があります。コンテキスト切り替えを管理する便利な方法は、PowerBIClient オブジェクトを格納するクラスレベルの変数を宣言することです。その後、変数に正しいオブジェクトを設定するヘルパーメソッドを作成できます。

// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;

// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {

    if (profileId.Equals("")) {
        pbiClient = GetPowerBIClient();    
    }
    else {
        pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
    }
}

サービスプリンシパルプロファイルを作成または管理する必要がある場合は、パラメーターなしで SetCallingContext メソッドを呼び出すことができます。この方法で、サービスプリンシパルの ID を使用してプロファイルを作成および管理できます。

// Always create and manage profiles as the service principal
SetCallingContext();

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

新しい顧客テナントのワークスペースを作成して設定する必要がある場合は、そのコードをサービスプリンシパルプロファイルとして実行する必要があります。したがって、プロファイルの ID を渡して SetCallingContext メソッドを呼び出す必要があります。この方法で、サービスプリンシパルプロファイルの ID を使用してワークスペースを作成できます。

// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);

// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);

特定のサービスプリンシパルプロファイルを使用してワークスペースを作成および構成したら、引き続き同じプロファイルを使用してワークスペースのコンテンツを作成および設定する必要があります。セットアップを完了するために SetCallingContext メソッドを呼び出す必要はありません。

開発者向けサンプル

AppOwnsDataMultiTenant という名前のサンプルアプリケーションをダウンロードすることをお勧めします。

このサンプルアプリケーションは、.NET 6 と ASP.NET を使用して開発されたもので、この記事で説明されているガイダンスと推奨事項を適用する方法を示しています。このコードを確認して、サービスプリンシパルプロファイルを使用して "顧客向け埋め込み" シナリオを実装するマルチテナントアプリケーションを開発する方法を学習できます。

この記事に関する詳細については、次のリソースを参照してください。

Share via

Power BI 埋め込みを使用してスケーラブルなマルチテナントアプリケーションを開発する

マルチテナントアプリケーション開発

1,000 ワークスペースの制限

セマンティックモデルとデータソース資格情報の分離を管理する

セマンティックモデルの所有権

データソース資格情報

サービスプリンシパルプロファイルより前の設計戦略

サービスプリンシパルプロファイル

サービスプリンシパルプロファイルが Microsoft Entra に認識されない

最上級のセキュリティプリンシパルであるサービスプリンシパルプロファイル

REST API 呼び出しをサービスプリンシパルプロファイルとして実行

Profiles REST API 操作を使用する

サービスプリンシパルプロファイルを作成する

サービスプリンシパルプロファイルを削除する

すべてのサービスプリンシパルプロファイルを取得する

サービスプリンシパルプロファイルを使用して REST API 呼び出しを実行する

開発者向けサンプル

フィードバック

フィードバック

その他のリソース

Share via

Power BI 埋め込みを使用してスケーラブルなマルチテナント アプリケーションを開発する

マルチテナント アプリケーション開発

1,000 ワークスペースの制限

セマンティック モデルとデータ ソース資格情報の分離を管理する

セマンティック モデルの所有権

データ ソース資格情報

サービス プリンシパル プロファイルより前の設計戦略

サービス プリンシパル プロファイル

サービス プリンシパル プロファイルが Microsoft Entra に認識されない

最上級のセキュリティ プリンシパルであるサービス プリンシパル プロファイル

REST API 呼び出しをサービス プリンシパル プロファイルとして実行

Profiles REST API 操作を使用する

サービス プリンシパル プロファイルを作成する

サービス プリンシパル プロファイルを削除する

すべてのサービス プリンシパル プロファイルを取得する

サービス プリンシパル プロファイルを使用して REST API 呼び出しを実行する

開発者向けサンプル

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

Power BI 埋め込みを使用してスケーラブルなマルチテナントアプリケーションを開発する

マルチテナントアプリケーション開発

セマンティックモデルとデータソース資格情報の分離を管理する

セマンティックモデルの所有権

データソース資格情報

サービスプリンシパルプロファイルより前の設計戦略

サービスプリンシパルプロファイル

サービスプリンシパルプロファイルが Microsoft Entra に認識されない

最上級のセキュリティプリンシパルであるサービスプリンシパルプロファイル

REST API 呼び出しをサービスプリンシパルプロファイルとして実行

サービスプリンシパルプロファイルを作成する

サービスプリンシパルプロファイルを削除する

すべてのサービスプリンシパルプロファイルを取得する

サービスプリンシパルプロファイルを使用して REST API 呼び出しを実行する