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

プレビュー

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

このモデルでは、ポータルがユーザーの行動を決めるのをやめ、Dataverseが決定します。各ポータルの連絡先はそれぞれのDataverseユーザーによって裏付けられ、すべてのリクエストはそのユーザー として 行われ、アクセスは そのユーザーのセキュリティロール が許可するもので行われます。これはモデル駆動型アプリを支配するセキュリティモデルと同じです。ポータル内の情報は一切参照されず、ポータル内の何も拡張できません。問題は、その役割がどこから来るかです。Dataverseはプロビジョニングされたポータルユーザーに プラットフォームが生成 した役割のみを持たせており、それを生成するのはPower Pagesだけです。したがって、このモデルはPower Portals Proの他の部分では決して使わない形でPower Pagesに依存しています。ステップ3でどこまで行っているかが詳しく説明されています。

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

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

Dataverseユーザーで連絡先をバックするには、Power Pagesのコンポーネントが環境に入った場合にのみ存在するプラットフォーム機能に依存しています。すなわち、 システム管理ユーザー、ライセンス費用がかかり、偽装可能なユーザーレコードです。もし環境がPower Pagesサイトをホストしたことがなければ、 今すぐ作成 してください。どのテンプレートでも問題ありませんし、トライアルサイトでも問題ありません。「 サイトを作成および管理」を参照してください。これらのコンポーネントからは2つの要素が生まれます。各連絡先がバックアップされるユーザーと、そのユーザーが保持できるセキュリティロールです。

注記

サイトに料金を払ったり運営を維持したりする必要はありません。フレームワークコンポーネントがインストールされ、セキュリティ機能が有効化されたら、ウェブサイト自体を削除できます。設定で参照されるPower Pages のサイトレコード (powerpagesite)はそのまま残らなければなりません。なぜなら、各プロビジョニングされたユーザーはそのレコードに対して powerpagesusermapping 行に記録されているからです。これは連絡先とDataverseユーザーの間のリンクです。

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

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

3. ウェブロールおよびテーブル権限でアクセス権を付与する

アクセスは、各連絡先の背後にあるDataverseユーザーが持つセキュリティロールから得られますが、これらは自分で作成できる役割ではありません。Dataverseは、プロビジョニングされたポータルユーザーに対してシステム 生成 の役割のみを受け入れており、それを生成するのはステップ2で有効にした機能だけです。サイト内の各ウェブロールごとにペアの PowerPages_* ロールを作成し、プラットフォームは連絡先のウェブロールメンバーシップが変わるたびにそれを割り当てたり解除したりします。したがって、ポータルユーザーがアクセスできるものはウェブロールとそれに付随するテーブル権限によって決まります。Power Pages管理アプリで編集するか、Power Portals Pro Enhanced Authorizationソリューションをインストールしている場合は、ポータル自身の Webロール ページで編集されます。Power Portals Proの中で、Power Pagesのコンセプトが誰かが到達できる範囲を決定するのは、プラットフォームの要件であり、私たちの設計ではありません。ユーザーがどのレコードにアクセスするかは、所有権の深さではなく各テーブルの 権限範囲によって決まります。生成されたロールの各権限は、そこから派生したプラットフォームレコードフィルターを持ちます。あるテーブルを読むことは別のテーブルにもアクセス可能であり、アカウントを読むことはアドレスも読み取るため、関連するテーブルにもテーブル権限が必要です。詳細は 「テーブル権限」を参照してください。

注記

なぜ自分で作成したロールを単に割り当てられないのか。 クリーンな環境で検証:プロビジョニングされたポータルユーザーに通常のセキュリティロールを割り当てると 「システム管理ユーザータイプは割り当てられている役割に対して有効でない」と表示され、APIを通じてシステム生成とマークされたロールの作成は 「無効な操作が実行されました」 と表示されて拒否されます。この制限はポータルプロビジョニングのユーザータイプに特有であり、アプリケーションユーザーなど他のシステム管理ユーザーは不満なく普通の役割を保持します。

4. ユーザーにウェブロールを与える

連絡先はウェブロールを保持することでその役割のアクセス権を得ます。ウェブロールを自動的に新規ユーザーに渡すには、 Power Portals Pro Enhanced Authorization ソリューションをインストールし、ポータルの Web ロール ページ(WebRoleAdmin、両方のプロジェクトテンプレートに含まれている)にルールを追加してください。各ルールはすべての新規ユーザー、またはFetchXMLルールに適合するユーザーにウェブロールを与えます。ルールは1つの連絡先につき1回実行されます — ポータルが登録した時と、既存の連絡先が外部ログインで初めてサインインした時などです。したがって、管理者が後で削除したウェブロールはそのまま削除されます。Power Pages Managementアプリで手動でウェブロールを割り当てることも可能です。

注記

強化認可ソリューションはPower Pagesに依存しているため、Power Portals Pro Coreとは別です。ウェブロールを割り当てるには、ポータルのアプリケーションユーザーはRead on the Webロール設定テーブル、ウェブロールにはRead and AppendTo、サイトコンポーネント(powerpagecomponent)でRead, Append, AppendToが必要です。Power Pagesはウェブロールを保存します。Webロールページはサインインした管理者として動作し、Dataverseはユーザーとアプリケーションユーザーの両方ができることのみを許可しているため、アプリケーションユーザーは設定テーブル上でCreate, Write, Delete, Append;WebロールでCreate, Write, Delete, Append;テーブル権限(mspp_entitypermission)でCreate, Read, Write, Delete, AppendTo;Create, Write and Delete, on site components;およびウェブサイト上のAppendTo(mspp_website)です。なぜなら、すべてのWebロールとテーブル権限はそれぞれ所属するサイト名を付けているためです。

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

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

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

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

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

7. ユーザーが実際に何ができるかを確認する

プロビジョ化されたユーザーは連絡先が初めてサインインしたときに作成されるため、最速のチェックは実際のポータルユーザーとしてサインインし、できることとできないことを試すことです。アクセス権はまさにセキュリティロールが許すもので、ポータル側の設定はその前に置かれず、ポータル内の何も広がらないのです。

ヒント

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

匿名の訪問者

サインアウトした訪問者も同じ仕組みで保護されます。プラットフォームはサイト のために匿名の システム管理ユーザー(アイデンティティ PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com )を作成し、Power Portals Proは認証されていないすべてのリクエストに対してそれを代行します。そのユーザーが持つセキュリティ役割は匿名の訪問者がアクセスできる範囲なので、サインアウトした訪問者が持つべき狭い読み取り専用アクセスだけを与え、それ以上のものは与えません。

注記

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

ポータル独自のテーブルセキュリティはどうでしょうか?

このモデルのセッションは、テーブル登録が記述するすべてのもの――操作、列、行範囲、所有権スタンプ( AddTableAccess で説明したか ITablePermissionProvider で書いたかに関わらず)をバイパスします。これは内部 systemuser のサインインと全く同様で、Dataverseが強制しているからです。ユーザーがどの行に到達し、どのレコードに属するかは、他のすべてと同様にセキュリティロールによって決定されます。これらの内容を書き込んだり登録したりする必要はありません。登録は、プロビジョニングされたユーザーによってバックアップ されていない セッション(機能が無効化された場合、プロビジョニングが失敗してフレームワークがポータル側のセキュリティにフォールされた場合、匿名ユーザーなしのサイトの匿名訪問者)をゲートするため、既存のポータルは段階的に移行できます。ポータルの役割もこれらのセッションには適用されません。このモデルでは割り当ても読み取れもしません。

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

セッションはPortalUserTypeのエナックの整数値を保持するPortalUserTypeクレームを持ちます:Contact(クラシックポータルユーザー)、SystemUser(実際の内部サインイン)、またはContactStubUser(プロビジョニングされたシステム管理ユーザーによって裏付けられた連絡先)。ContactStubUserセッションはさらに、権威あるpowerpagesusermappingレコードから解決されたプロビジョニングされたユーザーのIDを含むSystemUserIdクレームを保持します。同じ列挙はGET /api/auth/meCurrentUserResponse.PortalUserTypeと同じ返されます。ClaimsPrincipalではGetPortalUserType()およびGetDataverseSystemUserId()拡張を使用し、ContactStubUserセッションを内部ユーザーとして提示してはなりません。

ロールクレームも同じモデルに従います。プロビジョニングされたユーザーのセッションは、管理者が割り当てた 名前であるウェブロール と、それにペアリングされた PowerPages_* セキュリティロールを持ち、ポータルロールは含まれません。Blazorで [AuthorizeWebRole("Dealers")] または <PortalRoleView WebRole="Dealers"> 、Reactで <AuthorizedView webRoles="Dealers"> したウェブロールをゲートします。 GET /api/auth/me それらを webRolesとしてリストします。

API参照