SystemUserサインイン

Power Portals Proは、デフォルトのcontact支援ユーザーとともに、サインインしたDataverseのsystemuser記録をポータルユーザーとして認識します。設定は不要です。ユーザーがMicrosoft認証でサインインすると、ポータルはまず対応するsystemuserを探します。存在すればセッションはそのsystemUserとして実行され、Dataverseは偽装によってセキュリティを強制します。一致するシステムユーザーが見つからなければ、サインインは接触経路に戻されます。同じポータルは、Dataverseライセンスを持つ社内のスタッフと外部の顧客連絡先の両方に同時に対応可能です。

これが重要な時

システムユーザー支援フローは、以下のような場合に有用です。

このポータルは、すでにシステムユーザーとしてプロビジョニングされているスタッフ、従業員、サポートエージェント、Dataverseライセンスを持つパートナーにサービスを提供しています。
Dataverseのセキュリティ役割は、ユーザーが何を見たり何をしたりできるかの唯一の真実の源となるべきです。
すべてのスタッフユーザーごとに並行した contact 記録を維持することで、身元を重複させるのは避けたいです。

Microsoft認証のみ
Microsoft/Entra IDの外部プロバイダーのみがシステムユーザーに解決できます。ユーザーは systemuser.azureactivedirectoryobjectidとマッチングされ、 isdisabled = true を持つSystemUserはブロックされます。ローカルのユーザー名やパスワード、その他の外部プロバイダー(Googleなど)は常に連絡先としてサインインします。

仕組み

Microsoftのサインイン時に、ポータルは以下の通りです:

認証済みのAzure ADオブジェクトIDを systemuser.azureactivedirectoryobjectidと照らします。アクティブなレコードが一致すると、そのセッションはそのシステムユーザーに割り当てられます。
そうでなければ、外部ログインを adx_externalidentity経由で一致させるコンタクトバックフローに戻ります。
システムユーザーセッションでは、 ServiceClient.CallerId が systemuserid に設定され、すべてのDataverse通話がサインイン済みユーザーとして実行されます。これは彼らのセキュリティロール、事業ユニットのスコープ、行レベルのアクセス権です。ポータル側の ITablePermissionHandler や ITableRecordPermissionHandler インスタンスはリクエストをバイパスされます。
グリッド、フォーム、ボタンはユーザーの実際のDataverse権限を反映しており、 RetrieveUserPrivilegesRequest から計算され、ユーザーごとにキャッシュされています。接触セッションはこれまでと同様に登録されたハンドラーを経由して流れ続けます。

セキュリティモデル

システムユーザー支援セッションの場合、 CallerId なりすましはDataverseに強制を委ねるため:

レコードレベルおよびカラムレベルのセキュリティは、サインインしたユーザーのDataverseセキュリティロールから得られ、ポータルコードからではありません。
現場レベルのセキュリティ、階層的な所有権、事業部門のスコープ設定はすべて自動的に適用されます。
ポータル側の許可ハンドラー(ITablePermissionHandler / ITableRecordPermissionHandler)はリクエスト時にバイパスされます。同じポータル内でのコンタクトバックセッションでは通常通り実行されます。
ユーザーのDataverseセキュリティロールは ClaimTypes.Role クレームとしてプリンシパルに投影されるため、既存の [Authorize(Roles = "…")] 属性や User.IsInRole(...) チェックが、リクエストごとに追加のDataverse往復なしでも、プリンシパルに対して不利に働きます。請求は主正検証時に更新されるため、Dataverseでの役割割り当てはセキュリティスタンプ間隔(~10分)以内に再サインインを強制されることなく開始されます。

管理者:連絡先としてテスト

ポータル管理者は通常、コンタクト側の体験を確認する必要があります — ログインした顧客に対してホームページが正しく表示されるか?このケースは正しくツールバーボタンを隠していますか?— 管理作業を行う能力を失うことなく。Power Portals Proはこれを直接サポートしています。管理者はMicrosoftのサインインを1つのMicrosoftサインインを systemuser (内部アカウント)と contact (テストレコード、または自分の顧客側のレコード)の両方にリンクさせ、サインアウトせずに両者を切り替えることができます。

サインイン時に選択。 Microsoftのサインインが複数のIDに解決されると、コールバック後のページには各候補(種類+表示名+メールアドレス)をリストアップした選択ツールが表示されます。一方を選ぶと、そのユーザーをセッションの残りの間、そのIDとしてサインインします。
覚えておいた選択です。 選択者はプロバイダーごとに小さなクッキーを書き込むので、その後のサインインはプロンプトを飛ばして最後に選んだIDに直接進みます。記憶された選択はユーザーがセッション中に切り替えるたびに更新されるため、次の曖昧なサインインは新しい優先事項を尊重します。
セッション中の切り替え。 サインインしたユーザーが兄弟姉妹のアイデンティティを持っている場合、プロファイルメニューに 「Switch to contact」/「Switch to systemuser 」のエントリが表示されます。このアカウントは /api/auth/switch-identityに投稿され、は別アカウントIDの認証クッキーを再発行します。OAuthの往復は不要です。エンドポイントはプリンシパルからalt-identity idを読み取ります(リクエスト本体からは読み取らないため)、改ざんされたクリックでユーザーが別の人としてサインインできません。

混合オーディエンス:データ設計をそれに応じて行う
単一のポータルで、システムユーザーと連絡先の両方のユーザーを同一展開でサポートできます。カスタマイズにFetchXMLフィルター( adx_contactid == currentUserId ごとに行をスコープするフィルターが含まれている場合(これは接触専用ポータルでよく見られるパターン)、サインインしているユーザーがsystemuserの場合、そのフィルターは意味をなさなくなります。ユーザータイプにカスタマイズコードを分岐させて、各オーディエンスがそのデータを見るようにしましょう。

特権キャッシュ

環境全体の特権メタデータマップは、アプリケーション起動時に一度読み込まれ、無期限にキャッシュされます。アプリケーションを再起動(または IPrivilegeMetadataCache.InvalidateAsync呼び出す)ことで、新しいテーブルや権限スキーマの変更を取り入れてください。サインインした各システムの実効権限は24時間キャッシュされ、1 IUserPrivilegeCache.InvalidateAsync(userId)で追放可能です。