Dataverse接続設定

あなたのポータルは、たまたま閲覧している訪問者としてではなく、独立したアプリケーションとしてDataverseと通信します。これは2つの要素から成り立っています。Microsoft Entra IDでの アプリ登録 が認証情報を所有し、もう1つはDataverse環境内の アプリケーションユーザーが その認証情報にアイデンティティとセキュリティ役割を与えることです。このページは両方を説明し、ポータルが実際に必要とするアクセスについて説明しています。

これはサインインアプリではありません

この登録はポータル自身のサービスアイデンティティであり、ポータルに代わってデータの読み書きを行い、認証情報は D365:ClientId / D365:ClientSecretに分類されます。もう一つの別の登録は、 Microsoftでのユーザーのサインイン を担当します。分けておけばいい:これはリダイレクトURIや権限の委任を必要としませんが、環境内ではるかに大きな権限を持っています。 Entra IDサインイン設定をご覧ください

1. 申請書の登録

Dataverse環境を所有するテナントの Microsoft Entra管理センターで登録を作成します。

  1. Entra ID>アプリの登録をブラウズし、「新しい登録」を選択してください。
  2. ポータルと環境を識別する 名前 を入力してください。例えば Contoso Portal — Dataverse (Production)。同意画面では誰も見ないので、後で監査する人のために明確にしておくべきです。
  3. サポートアカウント タイプの中で「 シングルテナントのみ」を選択してください。このアイデンティティは組織から離れることはありません。
  4. リダイレクトURIは空のままにしてください。ここではユーザーがリダイレクトされることは一切ありません。ポータルはクライアントの認証情報フローで認証し、マシン間で認証を行い、ブラウザは関与しません。
  5. 登録を選択します。
  6. 概要ページでアプリケーション(クライアント)IDをコピーします。その値はD365:ClientIdになり、ステップ4でアプリケーションユーザーを作成する際に再度必要です。

2. クライアントシークレットを作成する

シークレットはポータルの唯一の認証情報なので、環境のデータへの鍵として扱ってください。

  1. 「Management」の「Certificates and secrets」を開いて「Clients secrets」タブを選択してください。
  2. 新しいクライアント秘密を選択し、環境(例:portal-production)で記述し、期限を選びます。
  3. Value列をすぐにコピーしてください — Secret IDはコピーしないでください。一度だけ表示され、D365:ClientSecretになります。

重要

シークレットが切れると、ポータルはDataverseに完全に届かなくなります。機能だけでなく、すべてのリクエストに対してです。ですので、有効期限をどこかに記載してください。本番環境では、証明書認証情報が有効期限の崖を避け、 AuthenticationType.Certificate は秘密の代わりに証明書を受け入れます。

3. API権限:不要

このステップは意図的に空にしており、それが多くの人を驚かせています。古いガイダンスでは、 Dynamics CRM → user_impersonation 委任権限を追加するように指示されています。その権限は サインインしたユーザーの代理として動作するアプリケーションのためのものです。しかしポータルはそれを行わず、認証は自分自身として行われ、そのアクセスは次のステップで作成したDataverseアプリケーションユーザーから完全に行います。

注記

Microsoft自身のサーバー間ガイダンスも同じことを述べています。アプリとして接続すると、 組織ユーザーとしてAccess Dynamics 365を付与しません。なぜなら、アプリケーションは特定のユーザーアカウントに紐づいているからです。追加しても何も壊れませんが、ポータルが決して行使しない機能が与えられます — それはオフにしてください。

4. Dataverseでアプリケーションユーザーを作成する

アプリの登録だけではデータには触れられません。Dataverseはユーザーレコードを割り当てる必要があり、それがクライアントIDを環境が認識するアイデンティティに変換します。

  1. Power Platform管理センターにサインインしてください。
  2. ナビゲーションペインで 「管理 」を選択し、次に 「環境」→「あなたの環境」を選びます。
  3. 「 設定 > ユーザー+権限 」> アプリケーションユーザーを選択します。
  4. + を選択:新しいアプリユーザー。
  5. +アプリを追加を選択して、ステップ1のクライアントIDまたは名前で登録を検索し、追加を選択します。このリストにはEntraアプリの登録のみが表示され、エンタープライズアプリケーションには含まれません。
  6. 事業部門を選択してください。ルート事業部門が通常の答えです。子ユニットは、セキュリティ役割が適用される前からポータルが到達できる範囲を絞り込みます。
  7. セキュリティロールの横にある編集アイコンを選択し、ポータルに必要なロールを割り当ててください。次のステップではどのロールか、そしてなぜ複数のロールが存在するのかを説明します。
  8. 「 作成」を選択します。

ヒント

アプリケーションユーザーは有料ライセンスを消費せず、環境ごとにEntraアプリごとに登録は1つまでです。各環境ごとに別々の登録を設定し、開発アクセスを取り消しても本番環境には影響しません。

5. アプリケーションユーザーにセキュリティ役割を与える

アプリケーションユーザーはセキュリティロールを保持するまで何もできません。ルートは2つあり、どちらが正しいかは一つの質問に依存します。ポータル自体が表示しないデータにアクセスする認証情報が問題になるか?

最短の方法:システム管理者

システム管理者の割り当ては機能し、環境にデモやプロトタイプ、すでに公開されているサンドボックスなど、何も含まれていない場合には、誤りではなく合理的な選択です。ただ、意図的にそうしてください。ポータルはインターネット対応であり、この認証情報が秘密が漏洩した場合に攻撃者がどこまで進むかを決めます。システム管理者とは、ポータルが表示するために作られたもののなかったすべてのテーブルを含む、環境内のすべてのテーブルを指します。

スコープ化されたルート:私たちの役割に加え、あなた自身の役割も

実際のデータが存在する場所なら、 2つの 役割を割り当ててください。セキュリティロールは加算的であるため、アプリケーションユーザーは両方の合同を持つことになります。そして、それらを分けておくことで、自分の助成金を読み返さずに確認できるようになります。

  1. 管理されたソリューションに付属する Power Portals Pro Application Userを割り当てます。フレームワークが実行するために必要なものだけを割り当て、それ以外は何も与えません。そして、同じ名前の カラムセキュリティプロファイル にアプリケーションユーザーを追加します。セキュリティロールはセキュアなカラムを付与できず、Power Pagesはフレームワーク自身として書く2つの連絡先カラム、 adx_identity_logonenabled と adx_identity_passwordhashを保護します。プロファイルがなければ、既存のユーザーは通常サインインし、最初の登録はログイン が有効なセキュアフィールドの作成権限を持っていないことになります。同様に、ポータルが接続するすべてのアプリケーションユーザー、特にデプロイされたアプリ内の管理されたアイデンティティに対しても同様に行います。
  2. 自分のテーブル用にもう一つカスタムロールを作成してください。Dataverseなら、それらを出荷されたロールに追加できますが、別々に設定できます。出荷済みロールは私たちのもので、ソリューションのアップグレードで再適用でき、そこに混じった助成金は私たちのロールを一緒に読まなければレビューできなくなります。MCPサーバーでは、 create_security_role 作成してアプリケーションユーザーに渡 assign_application_user_role 。
  3. その役割にテーブルを追加してください。MCPサーバーを使う場合は、security-roleフォームを経る必要はありません。 describe_role_table_privileges 、現在どの役割がテーブルでどの深さで付与されているかを示し、 add_table_privileges_to_role が欠けているものを付与します。付与は何も奪いません。 remove_table_privileges_from_role は権限を削除したり深さを下げたりし、誰も保持しなくなったら delete_security_role ロールを削除します。管理ロールには誰も触れず、出荷されたものも含めて、付与は必ずあなたのロールに入ります。

重要

強化認可の場合は、代わりに Power Portals Pro Application User - Enhanced Authorization を割り当ててください。 これは Power Portals Pro Enhanced Authorization ソリューションに同梱されており、上記の役割のスーパーセットです。同じ深さで付与されるすべての権限に加え、ウェブロールの読み取りやWebロール設定の維持に関する権限も含まれます。これは加入ではなく出荷された役割を置き換えるため、両方を割り当てるのは無害ですが意味がありません。これがなければポータルはウェブロールを読み取ることができません。新規ユーザーには役割を与えられず、ポータルはエラーを報告せずに何も表示しません。いずれにせよ、カラムセキュリティプロファイルは必要です。どんなに広範なセキュリティロールでも、セキュアなカラムを付与することはできません。

出荷された役割がすでにカバーしていること

Power Portals Pro Application User はフレームワーク自身が行う呼び出しから派生しており、当時は賢明と判断されたものではなく、フレームワークが実際に必要としているものを追跡します。

ポータルが何をするか 役割のニーズにアクセスする
ポータルユーザーにおけるレジスターとサインイン contact上でCreate, Read and Write、adx_externalidentityでCreate, Read, Write and Deleteを行い、ポータルユーザーと外部ログインのリンクを保存します。
グリッドをDataverseのビューにバインドし、値をフォーマットします savedqueryで読み、organizationで読む、usersettings、transactioncurrencyの日付、数字、通貨フォーマットを正しく確認してください。
確認メールとパスワードリセットメールを送信 設定した送信者アドレスが解決するqueueで、email上で、読み書き、読み取ってください。
ポータルの役割 ppp_portalroleとppp_portalroleconfigurationで作成、読み取り、書き込み、削除、contactで追加/追加を行い、役割を割り当てます。ポータル自体は実行時にのみこれらを読み取ります。書き込み権限は、コード内で役割を管理するホストが機能するようにするためRoleManager<PortalRole>であり、MCPサーバーのポータル役割ツールはアプリケーションユーザーとして接続されるプロジェクト内で機能します。
ウェブサイトのライセンスを検証します ppp_ProWebsiteLicenseCheckアクションを実行する権限とRead on ppp_powerportalsprowebsite — このアクションは呼び出し元のコンテキストで実行されるため、ウェブサイトの記録をアプリケーションユーザーとして読み取ります。どちらかが欠落すると、すべてのライセンスエンドポイントが402を返し、これは権限の欠如ではなく、期限切れのライセンスのように読み取られます。
データバースネイティブセキュリティ systemuser上で作成、読んで、書く、businessunitとroleで、powerpagesusermapping上で作成・読書、powerpagesiteで読む、そしてなりすましが依存する「他者を代表する行為」特権を行使します。

意図的にカバーしていないのは 、あなた自身のテーブル です。私たちが提供するどのロールも、それが何であるかを知ることはできません。上記のカスタムロールはそのためです。ポータルが公開するすべてのテーブルで、訪問者が到達したい範囲で「作成、読み取り、書き出し、削除」を期待してください。それが作業の大部分であり、完全にあなたのアプリケーションに特化しています。

重要

なりすましは範囲を狭めるだけです。決して範囲を広げることはありません。 Dataverseネイティブのセキュリティの下では、ポータルはサインインした訪問者のIDを各リクエストに印を押し、Dataverseはその訪問者の権限とアプリケーションユーザーの 権限の交差 点を適用します。つまり、 操作は両者が その権限を保持している場合にのみ許可されます。したがって、アプリケーションユーザーの役割は、どの訪問者ができるかの上限となっています。テーブル上で自分のロールでRead権限を持つ訪問者は、アプリケーションユーザーがそれを持たなければ何も読み取れず、カスタムロールにテーブルを追加しても、訪問者に自分のすでに許可された役割以上の権限を与えることはありません。

6. 接続設定を保存する

ポータルは D365 セクションの設定からこれらを読み取ります。開発中はユーザーシークレットに保持し、ソース制御に到達しないようにしてください:

EmailSenderEmailAddress はポータルの発信メールの送信元アドレスです。環境内の queue または有効 systemuser に一致している必要があります。キューが通常選択で、ポータルメールを後に離れる可能性のある人物に紐づけないためです。

送信キューの作成

Exchange Onlineで始める:メールが送信されるべきアドレスポータル用に 共有メールボックス を作成します — no-reply@yourcompany.com が一般的な選択肢です。共有メールボックスはライセンスを必要としません。次に、メーカーポータルの Advanced settings → Queues →→ New で、キューにそのアドレスを指定し、保存します。DataverseはそのアドレスのExchange Onlineプロファイルに対してメールボックスレコードを作成します。返信しない送信者にとってキューは正しい解決策であり、ポータルを同僚のアカウントに向けるよりはずだ。そうでなければ同僚の名前はポータルが送信されるすべての自動メッセージに載っていて、その名前がポータルを離れると送信が全くできなくなる。

重要

メールボックスは承認と有効化が必要です。 キューのメールボックスレコードを開き、Office 365グローバル管理者かExchange管理者のみが行える「 メール 承認」を実行し、その後「 メールボックスのテスト&有効化」を実行します。それが完了するまでは、Dataverseはポータルが送信するすべてのメールを受け入れ、一つも届けません。エラーはポータルに届かないため、パスワードリセットメッセージが一度も届かなかったと報告されるまでは、まさに正常に動作するメールのように見えます。MCPサーバーの create_email_queue はキュー、承認、テストを一回の通話で行い、送信者が配信されていないことを check_email_sender 説明します。

ヒント

ホスト環境では、環境変数と同じキーや秘密ストアから提供し、コロンの代わりにダブルアンダースコア( D365__ClientId、 D365__Secret )を用います。これはコロンセパレータがプラットフォーム間で持ち運べないためです。

ヒント

Azureにデプロイしたら、ClientSecretを完全に削除できます。D365:ManagedIdentityIdをユーザー割り当ての管理IDのクライアントIDに設定すると、ポータルはそのIDとして認証されます。シークレットはなくなり、期限切れもありません。そのクライアントIDから作成された独自のアプリケーションユーザーが必要です。これはステップ4でまさにその通りです。別のテナントの環境でも、D365:TenantIdを設定し、そのIDはアプリ登録の認証情報D365:ClientIdになります。Azureのデプロイメントを参照してください。

7. 接続の配線

サーバープロジェクトはフレームワークを登録する際に ConnectionOptions を設定します:

プロジェクトテンプレートがこれを自動で書いてくれるので、生成されたプロジェクトでは追加するものは何もありません。3つの設定値を入力すれば接続が正常になります。ポータルを起動し、Dataverseデータに裏付けられたページを閲覧して確認してください。

トラブルシューティング