通过

后端身份验证和授权概述

  • 项目

Fabric 开发人员工作负载示例在后端具有以下身份验证流。

对从 Fabric 到工作负载的请求进行身份验证和授权

授权标头结构

授权标头使用特定的令牌格式：

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

此格式包括两个不同的令牌：

  • subjectToken：代表正在执行操作的用户的委托令牌。
  • appToken：特定于 Fabric 应用程序的令牌。

使用双令牌标头背后的理由有三个：

  • 验证：工作负载可以通过验证 appToken 来验证请求是否源自 Fabric。

  • 用户上下文：subjectToken 为正在执行的操作提供用户上下文。

  • 服务间通信：工作负载可以使用 subjectToken 获取代理 (OBO) 令牌，从而允许其使用用户令牌调用其他服务。

身份验证

对 SubjectAndAppToken 执行的主要身份验证检查为：

  • “授权标头值的验证和分析”是在 AuthenticateControlPlaneCall 方法中完成的。 令牌必须以“SubjectAndAppToken1.0”前缀开头，并包含两个令牌 - subjectToken 和 appToken。

  • Entra 令牌属性验证：在 ValidateAadTokenCommon 方法中验证 subjectToken 和 appToken 的常见 Microsoft Entra 令牌属性。 这些属性包括令牌签名、令牌生存期、令牌受众（工作负载应用受众）和令牌版本 (1.0) 和颁发者。

  • appToken 属性验证：appToken 不应具有 scp 声明，但应具有以应用作为值的 idtyp 声明。 我们还检查工作负载发布者租户 ID 中的 tid 声明。

    appToken 声明示例：

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700047232,
"nbf": 1700047232,
"exp": 1700133932,
"aio": "E2VgYLjBuv2l+c6cmm/iP/bnL2v+AQA=",
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"idtyp": "app",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.",
"sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"uti": "5bgMXs3uMUSAHCruRjACAA",
"ver": "1.0"
}

  • subjectToken 属性验证：确保 subjectToken 包含具有 FabricWorkloadControl 范围的 scp 声明，令牌中不存在 idtyp 声明，并且具有与 appToken 中相同的 appid。

    subjectToken 声明示例：

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700050446,
"nbf": 1700050446,
"exp": 1700054558,
"acr": "1",
"aio": "ATQAy/8VAAAAUgWRMRnBo4VGHvrKRykUXOXBNKS1cHnBxLrYkZJJGSjAVyJGBecbLdSud1GUakER",
"amr": [
    "pwd"
],
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"ipaddr": "46.117.19.50",
"name": "john doe",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.",
"scp": "FabricWorkloadControl",
"sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"unique_name": "user1@constso.com",
"upn": "user1@constso.com",
"uti": "_llZwmJoSUiHv-kw6tfDAA",
"ver": "1.0"
}

参阅 IAuthenticationService。

注意

我们示例代码中的所有验证都适用于版本 1.0 令牌。

授权

一旦确认请求源自 Fabric 服务（通过 appToken），Fabric 会根据其权限元数据验证用户是否具有执行该操作的必要权限。

对从工作负载到 Fabric 的请求进行身份验证和授权

工作负载控制请求

工作负载控制 API 是特殊的 Fabric API，通过其 Fabric 项生命周期管理来支持工作负载。 这些 API 使用相同的 SubjectAndAppToken1.0 授权标头格式。

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

来自工作负载的调用包括以下令牌：

  • subjectToken：用户委托令牌（通过 OBO 流获得），代表正在执行操作的用户。 Fabric 验证用户是否具备执行操作所需的权限。

  • appToken：特定于工作负载应用程序的令牌。 Fabric 检查该令牌是否来自相关 Fabric 项目所属工作负载的 Microsoft Entra 应用，并且该应用位于工作负载发布者的租户上。

请参阅 AuthorizationHandler 中的 ValidatePermissions 方法。

公共 API

为了调用公共的 Fabric API，工作负载应该获取一个具有相关 API 范围的标准 Microsoft Entra OBO 令牌，并将其作为持有者令牌传递到请求的授权标头中。

参阅 FabricExtensionController。

对从工作负载 FE 到工作负载 BE 的请求进行身份验证和授权

授权标头

从工作负载 FE 发送到工作负载 BE 的请求中授权标头使用标准持有者令牌。

身份验证

工作负载 BE 中的 AuthenticateControlPlaneCall 方法负责验证令牌。 执行的主要检查包括：

  • 令牌生存期：确保令牌处于其有效使用期内。

  • 签名：验证令牌的真实性。

  • 受众：检查令牌的受众是否与工作负载 Microsoft Entra 应用匹配。

  • 颁发者：验证令牌的颁发者。

  • 允许的范围：验证允许令牌访问的范围。

授权通过调用 ValidatePermissions 方法来实现。 此方法在相关 Fabric 项目的 Fabric 工作负载控制端点中调用 resolvePermissions API，并验证用户是否具有操作所需的权限。

长时间运行的操作 - 刷新令牌

授权通过调用 ValidatePermissions 方法来实现。 此方法在相关 Fabric 项目的 Fabric 工作负载控制端点中调用 resolvePermissions API，并验证用户是否具有操作所需的权限。

如果你的工作负载包括长时间运行的操作，例如在 JobScheduler 中，你可能会遇到令牌生存期不足的情况。 有关如何对长时间运行的进程进行身份验证的更多信息，请参阅长时间运行的 OBO 进程。