Dataverseネイティブセキュリティ設定

プレビュー

このセキュリティモデルは現在 プレビュー 段階で、Microsoftの 基盤となる統合されたDataverse セキュリティ機能とPower Portals Proのサポートの両方が利用されています。Power Portals ProはMicrosoftのリリーススケジュールに従い、機能がMicrosoftから一般公開されると、Power Portals Proのサポートもプレビューから終了します。プレビューの指定は、プレビュー段階でMicrosoftが行う可能性のある変更に対応するために存在しています。

Dataverseネイティブのセキュリティモデルにより、Dataverse自身が標準的なセキュリティロールを通じてポータルユーザーに対してセキュリティを強制できます。これらのロールはPower Pagesの設定通り、ウェブロールとテーブル権限で設定されています。このページでは、セットアップの全過程を端から端まで順に紹介します。

モデルの動作や権限ハンドラーとの関係については、 セキュリティ概要

1. Power Pagesフレームワークコンポーネントをインストールする

統一セキュリティモデルは、Power Pagesのウェブサイトが作成される際にMicrosoftがDataverse環境にインストールするコンポーネント上で動作します。もし環境でPower Pagesサイトをホストしたことがなければ、 今すぐ作成 してください。どんなテンプレートでも問題ありませんし、トライアルサイトでも問題ありません。Power Pagesのドキュメントにある 「サイトの作成と管理 」をご覧ください。

注記

サイトに料金を支払ったり、運営を維持したりする必要はありません。フレームワークコンポーネントをインストールし、セキュリティ機能を有効にした後は、ウェブサイト自体を削除できます。設定で参照されるPower Pages のサイトレコード (powerpagesite)は、ユーザーマッピングやセキュリティロール同期が環境に残るため、環境内に残らなければなりません。

2. サイトの統合データバースセキュリティを有効にする

Unify Power PagesのセキュリティをDataverseで行う手順に従って、Microsoftの統合Dataverseセキュリティ機能を有効にしてください。有効化されると、プラットフォームはサイトの各ウェブロールごとにペアリングされたDataverseセキュリティロール(PowerPages_*と名付けられたロール)を作成し、同期を維持します。

3. ウェブロールとテーブル権限の設定

Power Pages Managementアプリで、サイトのウェブロールやテーブル権限を作成(または調整)し、それぞれのテーブル権限を受信すべきウェブロールにリンクさせます。このモデルでアクセス権を付与する唯一のサポート方法であり、プラットフォームはリンクされたテーブルの権限を各ウェブロールの同期されたセキュリティロールの権限に変換します。スコープはPower Pages(グローバル、連絡先、アカウントなど)とまったく同じように機能するため、レコードレベルのアクセスルールもここで設定されています。

4. Power PagesのサイトIDを探す

PowerPortalsProはサイトの powerpagesite 記録のIDが必要です。直接クエリを出すこともできます。例えばブラウザで <your org url>/api/data/v9.2/powerpagesites?$select=name を開き、サイトの powerpagesiteid をコピーするなどです。

5. Power Portals Proでのプロビジョニングを有効にする

サーバーのProgram.csでSecurityOptionsを設定しましょう:

設定は起動時に検証されます — ProvisionSystemUsers が有効になると、 PowerPagesSiteId を設定し、既存の powerpagesite レコードに解決しなければならず、そうでなければアプリケーションはガイダンスから起動できません。ここからは、PowerPortalsProはシステム管理(C2)の systemuser と powerpagesusermapping レコードを自動的にプロビジョニングし、新規連絡先の登録時や既存の連絡先のサインイン時にそのユーザーになりすます。

6. 連絡先にウェブロールを割り当てる

Power Pages Managementアプリ内またはプログラム的に、 powerpagecomponent_mspp_webrole_contact 関係を通じて連絡先にウェブロールを割り当てることで、個々のユーザーにアクセスを付与できます。プラットフォームはウェブロールのメンバーシップ変更に応じて、同期されたセキュリティロールを自動的に割り当てたり削除したりします。

ヒント

Dataverseは各ユーザーの実効権限をサーバーノードごとにキャッシュするため、役割や権限の変更は割り当て後数秒から数分で効果が発動することがあります。テストやアクセスを許可し、すぐに対応するフローでこれを考慮してください。

匿名の訪問者

サインアウトした訪問者も同じモデルでカバーされます。Power Pagesは自動的にサイト用の 匿名 ユーザー(システム管理ユーザーでアイデンティティ PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com )を作成し、PowerPortalsProは認証されていないすべてのリクエストに対してそれをなりすます。Power Pagesの方法で匿名アクセスを許可する:Power Pages管理アプリでWebロールをサイトの 匿名ユーザー ロールとしてマークし、テーブル権限をリンクします。同期されたセキュリティロールは、サインアウトした訪問者が見られる内容を管理します。

注記

匿名ユーザーはPower Pagesによって怠惰に作成されるため、統一セキュリティ機能以前に作成されたサイトにはまだ匿名者が存在しない場合があります(これはサイトの非接触 powerpagesusermapping 記録を通じて発見されます。ユーザー自身は属性クエリに見えません。候補者はよく知られた匿名ユーザー名と照らし合わせて初めて承認されます)。見つからない場合、匿名の訪問者はポータル側のパーセンシャルハンドラーに頼り、登録されていないと 匿名のデータアクセスができません 。フレームワークは起動時に結果を記録し、定期的に再試行を行います。

許可ハンドラーはどうでしょうか?

このモデルのセッションは、内部systemuserサインインと同様に、ITablePermissionHandlerやITableRecordPermissionHandlerを完全にバイパスします。なぜならDataverseは、なりすましユーザーの役割を通じてネイティブにセキュリティを強制しているからです。権限ハンドラーコードを書いたり登録したりする必要はありません。ハンドラーは、偽装されたシステムユーザー(機能が無効化された場合、プロビジョニングに失敗してフレームワークがポータル側のセキュリティにフォールダウンした場合、匿名ユーザーなしでサイトに匿名訪問者がいる場合)に依然として適用されます。したがって、既存のハンドラーベースのポータルは段階的に移行可能です。

UIでプロビジョニング済みユーザーを区別する方法

セッションにはPortalUserTypeエノバンションの整数値を保持するPortalUserTypeクレームが搭載されます:Contact(クラシックポータルユーザー)、SystemUser(実際の内部サインイン)、またはContactStubUser(プロビジョニングされたシステム管理ユーザーによって裏付けられた連絡先);ContactStubUserセッションは、権限あるpowerpagesusermappingレコードから解決されたプロビジョニングされたユーザーのIDを含むSystemUserIdクレームも含みます。同じ枚数はGET /api/auth/meCurrentUserInfo.PortalUserType返されます。ClaimsPrincipalでGetPortalUserType()とGetDataverseSystemUserId()の拡張機能を使い、内部ユーザーとしてContactStubUserセッションを提示しないでください。

API参照