追加のコネクタ機能
この記事では、コネクタ開発者が投資できるさまざまな種類の追加のコネクタ機能について説明します。 この記事では、それぞれの種類について、可用性と、機能を有効にするための手順の概要を示します。
認証
認証の実装については、認証の記事で説明されていますが、コネクタ所有者がオファリングに関心を持つ可能性のあるその他の方法もあります。
[Windows 認証]
Windows 認証がサポートされます。 コネクタで Windows ベースの認証を有効にするには、コネクタの Authentication セクションに次の行を追加します。
Windows = [ SupportsAlternateCredentials = true ]
この変更により、Power BI Desktop 認証エクスペリエンスのオプションとして Windows 認証が公開されます。 SupportsAlternateCredentials フラグによって、"代替資格情報を使用して接続する" オプションが公開されます。 このフラグを有効にした後で、明示的な Windows アカウントの資格情報 (ユーザー名とパスワード) を指定できます。 この機能を使用して、独自のアカウント資格情報を提供することで偽装をテストできます。
シングル サインオン認証
このセクションでは、認定済みのコネクタにシングル サインオン (SSO) 機能を実装するために使用できるオプションの概要を示します。 現在、SSO の "プラグ アンド プレイ" 拡張機能はサポートされていません。 SSO を有効にすると、Microsoft とデータ ソースまたはコネクタ側の両方で変更とコラボレーションが必要になるため、作業を開始する前に Microsoft の担当者にお問い合わせください。
Azure Active Directory SSO
クラウドのシナリオでは、Azure Active Directory (Azure AD) ベースの SSO がサポートされています。 データ ソースで Azure AD アクセス トークンを受け入れる必要があります。これは、Power BI Azure AD ユーザー トークンが Azure AD からのデータ ソース トークンと交換されるためです。 認定済みのコネクタがある場合は、Microsoft の担当者に問い合わせて詳細を確認してください。
Kerberos SSO
Kerberos ベースのシングル サインオンは、ゲートウェイのシナリオでサポートされています。 データ ソースで Windows 認証をサポートする必要があります。 一般的に、これらのシナリオには、直接クエリベースのレポートと、ODBC ドライバーに基づくコネクタが含まれます。 ドライバーの主な要件は、現在のスレッド コンテキストから Kerberos 構成設定を特定でき、スレッドベースのユーザー偽装がサポートされていることです。 ゲートウェイは、Kerberos の制約付き委任 (KCD) をサポートするように構成する必要があります。 例については、Impala サンプル コネクタを参照してください。
Power BI により、現在のユーザー情報がゲートウェイに送信されます。 ゲートウェイでは Kerberos の制約付き委任を使用して、偽装したユーザーとしてクエリ プロセスを呼び出します。
上記の変更を行った後、コネクタ所有者は次のシナリオをテストして機能を検証できます。
- Power BI Desktop の場合: Windows の偽装 (現在のユーザー)
- Power BI Desktop の場合: 代替資格情報を使用した Windows の偽装
- ゲートウェイの場合: 代替資格情報を使用した Windows の偽装。この場合、ゲートウェイ Power BI 管理ポータルで Windows アカウントの資格情報を使用して、データ ソースを事前に構成します。
コネクタ開発者はこの手順を使用して、Kerberos ベースの SSO の実装をテストすることもできます。
Power BI Kerberos SSO ドキュメントの記事の手順を使用して、シングル サインオンを有効にしたオンプレミス データ ゲートウェイを設定します。
SQL Server および Windows アカウントでテストして、セットアップを検証します。 SQL Server Kerberos 構成マネージャーを設定します。 SQL Server で Kerberos SSO を使用できる場合は、他のデータソースでも Kerberos SSO が有効になるように、Power BI データ ゲートウェイが適切に設定されています。
ODBC ドライバーを使用してサーバーに接続するアプリケーション (コマンドライン ツールなど) を作成します。 アプリケーションで接続に Windows 認証を使用できることを確かめます。
ユーザー名 (UPN) を引数として取り、それと共に WindowsIdentity コンストラクターを使用できるように、テスト アプリケーションを変更します。 完了したら、手順 1 で設定したゲートウェイ アカウントに付与された権限を使用して、ユーザーの AccessToken プロパティを取得し、このトークンを偽装できるはずです。
アプリケーションに変更を加えたら、偽装を使用して、ODBC ドライバーを介してサービスに読み込んで接続できることを確かめます。 データを取得できることを確かめます。 代わりにネイティブ C または C++ コードを使う場合は、Lsaloginuser を使用して、ユーザー名のみを持つトークンを取得し、KERB_S4U_LOGON オプションを使用する必要があります。
この機能が検証された後、Microsoft では、Power BI サービスからゲートウェイに至るまで UPN をスレッド化するように変更を加えます。 ゲートウェイに達すると、基本的にデータを取得するテスト アプリケーションと同じように動作します。
この変更を要求する方法の詳細については、作業開始前に Microsoft の担当者にお問い合わせください。
SAML SSO
SAML ベースの SSO は多くの場合、エンド データ ソースでサポートされておらず、推奨される方法ではありません。 ご自分のシナリオで SAML ベースの SSO を使用する必要がある場合は、Microsoft の担当者に問い合わせるか、ドキュメントを参照して詳細をご確認ください。
ネイティブ データベース クエリのサポート
一部の Power Query コネクタでは、エンド ユーザーは接続エクスペリエンスの [詳細設定] でネイティブ データベース クエリを指定できます。 カスタム コネクタの開発者は、コネクタでネイティブ データベース クエリのサポートを提供することに関心がある場合があります。
ユーザーが ODBC ベースのカスタム コネクタを使用してカスタム SQL ステートメントを実行できるようにする
シナリオ: エンド ユーザーは ODBC ベースのコネクタを使用して、カスタム SQL ステートメントを実行できます。 そのステートメントはインポート モードで実行され、変換をフォールドする必要はありません。
状態: この機能は現在、機能拡張 SDK ではサポートされていません。 製品チームは、このシナリオの実行可能性を調査しています。 セキュリティ モデルに拡張性がない場合、以下のいずれかの回避策を使用しない限り、コネクタでネイティブ クエリ機能を公開しないようにすることをお勧めします。
回避策: データ ソースで、現在ネイティブ データベース クエリをサポートしている汎用 ODBC コネクタを使用できる場合は、これを使用することをお勧めします。 しかし、汎用 ODBC 接続シナリオが動作しない場合もあります。たとえば、コネクタ レベルで認証を実装する必要がある場合です。
このような場合、コネクタ開発者は、カスタム コネクタではなく、Odbc.Query 関数で汎用 ODBC 機能を使用することを選択できます。 カスタム コネクタでドライバーの設定をオーバーライドし、クエリ フォールディングの動作を向上させることができる Odbc.DataSource とは異なり、Odbc.Query では単にクエリが指定どおりに実行されるため、カスタム コネクタ ラッパーの利点は得られません。
データ ソースで読み取り専用アクセスを適用でき、コネクタ用の Odbc.Query 機能の公開を続行する場合は、2 つ目のデータ ソース関数を独自の Publish レコードと共に提供し、[データの取得] ダイアログに 2 つのエントリ (DataSource.Database、DataSource.Query) を設定することをお勧めします。 Odbc.Query 関数では、直接クエリではなく、Power BI でのインポート モードのみがサポートされます。 Odbc.Query (クエリ フォールディングがサポートされない) と Odbc.DataSource (クエリ フォールディングがサポートされる) を組み合わせるとエンド ユーザーが混乱する可能性があるため、区別することをお勧めします。 また、必ず 2 つの Publish レコードの名前付けを明確に区別して、ネイティブ クエリに使用する機能をユーザーに明確に伝えてください。
データ ソースで読み取り専用アクセスが適用されない場合、コネクタでネイティブ データベース クエリ セキュリティ モデル機能を利用する必要もあります。 Visual Studio SDK ではネイティブ データベース クエリ プロンプトが動作しないことに注意してください。 Visual Studio で Extension.Query を実行しようとすると、エラーが表示されます。
The evaluation requires a permission that has not been provided. Data source kind: 'Extension'. Data source path: 'test'. Permission kind: 'Native Query'
Power BI Desktop でテストを行う必要があります。
次のコネクタ コード例では、2 つの関数 (1 つはネイティブ クエリを受け入れ、もう 1 つは受け入れないもの) を公開しています。
section Extension;
// This function would call Odbc.DataSource
[DataSource.Kind = "Extension"]
shared Extension.DataSource = (server as text) => server;
// This function would call Odbc.Query
[DataSource.Kind = "Extension"]
shared Extension.Query = (server as text, query as text) => query;
Extension = [
// MakeResourcePath overrides the default Data Source Path creation logic that serializes
// all required parameters as a JSON encoded value. This is required to keep the data source
// path the same between the Extension.DataSource and Extension.Query functions. Alternatively,
// you can provide a function documentation type and use DataSource.Path = false for the query
// parameter to exclude it from the data source path calculation.
Type="Custom",
MakeResourcePath = (server) => server,
ParseResourcePath = (resource) => { resource },
// Use NativeQuery to enable a Native Database Query prompt in the Power Query user experience.
NativeQuery = (optional query) => query,
Authentication=[Anonymous=null]
];
評価時に、データ ソース関数のパラメーター名をデータ ソース定義の NativeQuery 関数のパラメーター名にマップでき、NativeQuery 関数からテキストが返される場合、呼び出しサイトではネイティブ クエリ プロンプトが生成されます。 この場合、Extension.Query("server", "select 1") でネイティブ クエリ テキスト select 1 のチャレンジが生成されますが、Extension.DataSource("server") ではネイティブ クエリ チャレンジは生成されません。
ユーザーがカスタム SQL ステートメントに対して直接クエリを使用できるようにする
シナリオ: エンド ユーザーは、ネイティブ データベース クエリに対して直接クエリを使用できます。
状態: この機能は現在、機能拡張 SDK ではサポートされていません。 製品チームはこのシナリオを調査しており、このシナリオが最終的には、ODBC ドライバーと、ANSI SQL92 "パス スルー" モードをサポートするエンド データ ソースを使用するコネクタに対して利用できるようになることを期待しています。
回避策: なし。