Power BI Paginated Report：OAuth2 下方 SSO Checkbox 勾選與不勾選的區別
Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license.
If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1386
在 Power BI Service 中，RDL 使用 OAuth2 作為資料來源認證時，會看到下面這個 Checkbox：
レポート閲覧者は、DirectQuery または DirectLake モードで自分の Power BI ID を使用してこのデータ ソースにアクセスできます。
這個選項看起來有點抽象，但其實核心差異非常簡單。
先看結論：一句話理解
不勾選：Power BI 認人，Dataverse 不認 Viewer，由固定帳號代查。
勾選：Power BI 認人，Dataverse 也直接認 Viewer。
也就是說，Checkbox 真正決定的不是「Power BI 知不知道現在是誰」，而是：
RDL 查詢 Dataverse 時，到底使用誰的身份？
快速對照如下：
| 項目 | 不勾選 | 勾選 |
|---|---|---|
| 登入 Power BI 的人 | Viewer 本人 | Viewer 本人 |
=User!UserID |
Viewer 本人 | Viewer 本人 |
| 查詢 Dataverse 的身份 | 固定 OAuth2 帳號 | Viewer 本人 |
| Viewer 本身需要 Dataverse 權限 | 通常不需要 | 需要 |
| Dataverse Security Role 按誰生效 | 固定帳號 | Viewer 本人 |
| Dataverse 是否知道真正 Viewer 是誰 | 否 | 是 |
一、不勾選：由固定 OAuth2 帳號代替所有人查 Dataverse
設定如下：
認証方法：OAuth2
☐ レポート閲覧者は、自分の Power BI ID を使用して...
此時需要先使用一個具有 Dataverse 必要權限的帳號登入。
之後，不論誰查看 RDL，真正向 Dataverse 發出查詢的都是這個固定帳號。
例如：
Viewer A ─┐
Viewer B ─┼→ Power BI → RDL → 固定 OAuth2 帳號 → Dataverse
Viewer C ─┘
所以 Viewer A 本人即使沒有直接查詢 Dataverse 的權限，只要：
-
A 有權限開啟這份 Power BI RDL
-
固定 OAuth2 帳號有 Dataverse 必要權限
RDL 仍然可以取得 Dataverse 資料。
那 User!UserID 呢？
仍然可以正常取得。
例如 A 查看報表：
User!UserID
→ [email protected]
但 Dataverse 查詢身份可能是：
[email protected]
所以這時同時存在兩種身份：
誰正在看報表？
→ User!UserID
→ [email protected]
誰真正去查 Dataverse？
→ 固定 OAuth2 帳號
→ [email protected]
這兩件事互不衝突。
二、勾選：使用 Viewer 本人的身份查 Dataverse
設定如下：
認証方法：OAuth2
☑ レポート閲覧者は、自分の Power BI ID を使用して...
這時 Power BI 會把 Viewer 本人的身份傳給資料來源。
例如 A 查看報表：
Viewer A
↓
Power BI
↓
RDL
↓
A 本人的身份
↓
Dataverse
B 查看時則變成：
Viewer B
↓
Power BI
↓
RDL
↓
B 本人的身份
↓
Dataverse
因此 Dataverse 可以直接根據 A、B 各自的：
Security Role
Table 權限
Record-level 權限
TDS Endpoint 權限
決定能不能讀取資料。
所以勾選之後，每個 Viewer 自己就必須具備相應的 Dataverse 存取權限。
三、SSO 和 User!UserID 不是同一回事
這一點非常容易搞混。
SSO 並不是：
SSO
↓
User!UserID
↓
判斷權限
而是：
Viewer 的 Power BI / Entra 身份
↓
直接傳遞到資料來源
↓
Dataverse 根據該身份判斷權限
另一方面：
=User!UserID
是 RDL 內部取得「目前正在查看報表的人」所使用的值。
所以不論 Checkbox 勾不勾：
Viewer A
→ User!UserID = A
都成立。
Checkbox 只改變：
Dataverse 查詢到底使用 A 的身份，還是使用固定帳號的身份。
四、什麼情況下勾選 SSO 特別有意義？
例如 Dataverse 本身已經有完整的使用者權限設計：
管理者
→ Security Role A
→ 可以讀全部支部資料
一般使用者
→ Security Role B
→ 只能讀自己範圍資料
這時勾選 SSO 很有意義。
因為：
一般使用者
↓
自己的身份
↓
Dataverse
↓
Security Role
↓
不該看的資料直接不返回
RDL 就不需要重新實作一套相同的安全判斷。
五、但如果所有人的 Dataverse Security Role 都差不多呢？
這是另一種常見架構。
假設所有 Canvas App 使用者都被賦予同一個 Security Role，而且該 Role 對需要使用的業務表都有：
Create
Read
Write
Delete
真正的業務權限則是在 Canvas App 裡自己判斷。
例如：
使用者 Email
↓
查 Dataverse 使用者管理表
↓
判斷：
・是不是管理者
・是不是一般使用者
・屬於哪個支部
↓
Canvas App 控制功能和資料
這種情況下，即使勾選 SSO：
管理者 A → A 身份 → Dataverse
一般人 B → B 身份 → Dataverse
Dataverse 仍然可能看到：
A：有 Read 權限
B：也有 Read 權限
因為「A 是管理者、B 是一般使用者」這件事，根本不是 Dataverse Security Role 管的，而是 Canvas App 自己查表判斷的。
所以：
SSO 不會自動把 Canvas App 裡的業務權限邏輯搬到 RDL。
六、這種架構下，RDL 要怎麼做？
如果採用：
OAuth2
☐ 不勾 SSO
就可以讓 RDL 使用：
=User!UserID
取得目前 Viewer 的 Email。
然後：
User!UserID
↓
[email protected]
↓
查 Dataverse 使用者管理表
↓
確認有沒有註冊
↓
取得：
・支部
・使用者種類
・管理者權限
↓
限制真正的帳票查詢
例如：
[email protected]
→ 東京支部
→ 管理者
[email protected]
→ 大阪支部
→ 一般使用者
[email protected]
→ 查不到
→ 不允許取得帳票資料
如此一來，Canvas App 和 RDL 可以共同使用同一份 Dataverse 使用者管理資料。
七、Power BI 權限和 Dataverse 權限不要混在一起
還有一個容易混淆的地方。
即使使用固定 OAuth2 帳號：
Viewer
↓
Power BI
↓
RDL
↓
固定帳號
↓
Dataverse
也不代表任何人都能打開 RDL。
前面仍然有 Power BI 自己的權限控制。
所以可以分成三層：
第一層：Power BI
→ 這個人能不能打開 RDL？
第二層：RDL
→ 這個人是誰？
→ User!UserID
第三層：Dataverse
→ 誰真正執行資料查詢？
如果不勾 SSO：
第三層 = 固定帳號
如果勾 SSO：
第三層 = Viewer 本人
總結
最終只要記住下面這兩句就足夠：
不勾選：Power BI 認人，Dataverse 不認 Viewer，由固定帳號代查。
勾選：Power BI 認人，Dataverse 也直接認 Viewer。
而 =User!UserID 在兩種情況下都可以取得真正的 Viewer。
因此，該不該勾選的核心問題其實不是：
「我要不要取得 User!UserID？」
而是：
「我希望 Dataverse 的 Security Role 自己負責終端使用者的資料權限，還是希望 RDL 根據 User!UserID 和管理表自己判斷業務權限？」
如果所有使用者本身擁有不同且精確的 Dataverse Security Role，SSO 很有價值。
如果所有人的 Dataverse 權限基本相同，而管理者、一般使用者、所屬支部等資訊原本就是由 Canvas App 查 Dataverse 管理表判斷，那麼：
OAuth2
☐ 不勾 SSO
+
User!UserID
+
Dataverse 使用者管理表
通常更符合原本的系統設計。
This article was last edited at