如何在外部网站嵌入含行级安全（RLS）的报表？相关技术咨询

一、度量值逻辑需做的修改 #

• 若能通过身份验证流程正确传递用户UPN信息到Power BI，原有基于USERPRINCIPALNAME()的度量值逻辑无需修改，RLS规则可正常运行。
• 若外部网站使用独立的用户体系（非Azure AD），需做以下调整：
  • 将USERPRINCIPALNAME()替换为自定义身份标识（如外部网站的用户邮箱/ID），该标识需通过嵌入流程传递给Power BI。
  • 调整VALUELOOKUP的匹配条件，确保用传递过来的自定义标识能正确关联到对应的user_id。
  • 权限校验逻辑保持不变，只要能建立自定义标识与权限表的关联即可。

二、嵌入报表的身份验证方案 #

针对微软域外的外部网站，常用两种验证方式：

• 嵌入令牌（Embed Token）方案：
  1. 外部网站先完成自身的用户身份验证（如账号密码、第三方OAuth等）。
  2. 网站后端调用Power BI REST API，基于已验证的用户信息生成嵌入令牌，生成时可指定用户的身份参数（如effectiveIdentity）。
  3. 前端使用该令牌加载报表，Power BI会根据令牌中的身份信息应用RLS规则。
• Azure AD身份验证方案：
  外部用户需拥有Azure AD账号，打开嵌入报表时会跳转至Azure AD登录页完成验证，验证通过后Power BI获取用户UPN信息。该方案仅适合愿意使用Azure AD账号的外部用户，不推荐纯外部独立网站场景。

三、能否继续使用USERPRINCIPALNAME()？ #

• 使用Azure AD身份验证时：可以直接继续使用，用户登录后Power BI会自动获取其UPN，原有RLS逻辑完全生效。
• 使用嵌入令牌方案时：
  • 若生成令牌时指定了effectiveIdentity参数并传入有效UPN值，USERPRINCIPALNAME()会返回该指定值，可继续使用原有逻辑。
  • 若未指定effectiveIdentity，USERPRINCIPALNAME()会返回空值或服务主体名称，此时无法正常使用，必须改用自定义身份标识传递。

内容的提问来源于stack exchange，提问作者Carlos Sette