你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

管理应用服务身份验证的 API 和运行时版本

本文介绍如何在 应用服务中自定义内置身份验证和授权的 API 和运行时版本。

用于应用服务身份验证的管理 API 有两个版本。 Azure 门户中的身份验证体验需要 V2 版本。 在进行一些更改后,已使用 V1 API 的应用可以升级到 V2 版本。 具体而言,必须将机密配置移至槽粘滞应用程序设置。 可以从门户中应用的 “身份验证 ”部分自动移动机密配置。

更新配置版本

警告

迁移到 V2 会通过某些客户端(例如 Azure 门户、Azure CLI 和 Azure PowerShell 中的现有体验)禁用对应用程序的应用服务身份验证/授权功能的管理。 无法撤消此迁移。

V2 API 不支持像 V1 那样,以独立供应商的身份创建或编辑 Microsoft 帐户。 相反,它使用融合的 Microsoft 标识平台,允许使用 Microsoft Entra 和个人 Microsoft 帐户登录用户。 切换到 V2 API 时,使用 V1 Microsoft Entra 配置来配置 Microsoft 身份平台提供程序。 V1 Microsoft 帐户提供程序在迁移过程中继续使用,且正常运行,但您应迁移到较新的 Microsoft 身份平台模型。 有关详细信息,请参阅将 配置切换到 Microsoft Entra 提供程序

自动化迁移过程将提供程序机密移动到应用程序设置中,然后将其余配置转换为新格式。 若要使用自动迁移,请执行以下操作:

  1. 转到门户中的应用,然后在左窗格中选择 “设置>身份验证 ”。
  2. 如果应用配置了 V1 模型,则会看到 “升级 ”按钮。
  3. 选择“升级”按钮。 请查看确认提示中的说明。 如果已准备好执行迁移,请选择提示中的“升级”

手动管理迁移

如果不想使用前面所述的自动版本,请执行以下步骤,可以手动将应用程序迁移到 V2 API。

将机密移动到应用程序设置

若要将标识提供者机密移动到应用程序设置,请完成以下步骤。

  1. 使用 V1 API 获取现有配置:

    az webapp auth show -g <group_name> -n <app_name>
    

    在生成的 JSON 有效负载中,记下已配置的每个提供程序所用的机密值:

    • Microsoft Entra:clientSecret
    • Google:googleClientSecret
    • Facebook:facebookAppSecret
    • X:twitterConsumerSecret
    • Microsoft 帐户:microsoftAccountClientSecret

    重要说明

    机密值是重要的安全凭据,应谨慎处理。 不要共享这些值或将其保存在本地计算机上。

  2. 应为每个机密值创建槽粘滞应用程序设置。 可以选择每个应用程序设置的名称。 其值应与上一步中获取的内容匹配,或引用使用该值创建的 Azure Key Vault 机密

    若要创建设置,可以使用 Azure 门户,或为每个提供程序运行以下命令的变体:

    # For web apps, Google example    
    az webapp config appsettings set -g <group_name> -n <app_name> --slot-settings GOOGLE_PROVIDER_AUTHENTICATION_SECRET=<value_from_previous_step>
    
    # For Azure Functions, X example
    az functionapp config appsettings set -g <group_name> -n <app_name> --slot-settings TWITTER_PROVIDER_AUTHENTICATION_SECRET=<value_from_previous_step>
    

    注意

    此配置的应用程序设置应标记为槽粘滞,这意味着它们不会在槽交换操作期间在各环境之间移动。 此配置是必需的,因为身份验证配置绑定到环境。

  3. 创建名为 authsettings.json 的新 JSON 文件。 采用之前接收的输出,并删除其中的每个机密值。 将剩余输出添加到文件,确保不包含任何机密。 在某些情况下,配置可能具有包含空字符串的数组。 请确保 microsoftAccountOAuthScopes 不会。 如果这样做,请将值更改为 null

  4. authsettings.json 添加一个属性,该属性指向之前为每个提供程序创建的应用程序设置名称:

    • Microsoft Entra:clientSecretSettingName
    • Google:googleClientSecretSettingName
    • Facebook:facebookAppSecretSettingName
    • X:twitterConsumerSecretSettingName
    • Microsoft帐户: microsoftAccountClientSecretSettingName

    此操作后的设置文件可能如下所示,在本例中仅针对 Microsoft Entra ID 进行配置:

    {
        "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/mywebapp/config/authsettings",
        "name": "authsettings",
        "type": "Microsoft.Web/sites/config",
        "location": "Central US",
        "properties": {
            "enabled": true,
            "runtimeVersion": "~1",
            "unauthenticatedClientAction": "AllowAnonymous",
            "tokenStoreEnabled": true,
            "allowedExternalRedirectUrls": null,
            "defaultProvider": "AzureActiveDirectory",
            "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
            "clientSecret": "",
            "clientSecretSettingName": "MICROSOFT_IDENTITY_AUTHENTICATION_SECRET",
            "clientSecretCertificateThumbprint": null,
            "issuer": "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/",
            "allowedAudiences": [
                "https://mywebapp.azurewebsites.net"
            ],
            "additionalLoginParams": null,
            "isAadAutoProvisioned": true,
            "aadClaimsAuthorization": null,
            "googleClientId": null,
            "googleClientSecret": null,
            "googleClientSecretSettingName": null,
            "googleOAuthScopes": null,
            "facebookAppId": null,
            "facebookAppSecret": null,
            "facebookAppSecretSettingName": null,
            "facebookOAuthScopes": null,
            "gitHubClientId": null,
            "gitHubClientSecret": null,
            "gitHubClientSecretSettingName": null,
            "gitHubOAuthScopes": null,
            "twitterConsumerKey": null,
            "twitterConsumerSecret": null,
            "twitterConsumerSecretSettingName": null,
            "microsoftAccountClientId": null,
            "microsoftAccountClientSecret": null,
            "microsoftAccountClientSecretSettingName": null,
            "microsoftAccountOAuthScopes": null,
            "isAuthFromFile": "false"
        }   
    }
    
  5. 将此文件作为应用的新身份验证/授权配置提交:

    az rest --method PUT --url "/subscriptions/<subscription_id>/resourceGroups/<group_name>/providers/Microsoft.Web/sites/<app_name>/config/authsettings?api-version=2020-06-01" --body @./authsettings.json
    
  6. 验证应用在提交文件后是否仍按预期运行。

  7. 删除前面步骤中使用的文件。

现在,你已迁移应用,以将标识提供程序机密存储为应用程序设置。

将配置切换到 Microsoft Entra 提供程序

如果现有配置包含Microsoft帐户提供程序,并且不包含 Microsoft Entra 提供程序,则可以将配置更改为 Microsoft Entra 提供程序,然后执行迁移:

  1. 在 Azure 门户中转到 应用注册,找到与 Microsoft 帐户提供程序关联的注册信息。 它可能属于 “拥有的应用程序 ”标题。
  2. 转到注册的 “身份验证”(预览) 页。 在 “重定向 URI”下,应会看到一个以结尾的 /.auth/login/microsoftaccount/callback条目。 复制此 URI。
  3. 添加与刚复制的 URI 匹配的新 URI,但以 /.auth/login/aad/callback结尾。 此 URI 允许应用服务身份验证/授权配置使用注册。
  4. 在门户中转到你的应用。 选择 “设置>身份验证”。
  5. 收集 Microsoft 帐户提供程序的配置。
  6. 使用 高级 管理模式配置 Microsoft Entra 提供程序,并提供在上一步中收集的客户端 ID 和客户端机密值。 对于 颁发者 URL,请使用 <authentication-endpoint>/<tenant-id>/v2.0。 将 <authentication-endpoint> 替换为云环境的身份验证终结点(例如,适用于全局 Microsoft Entra ID 的 "https://login.microsoftonline.com")。 将 <tenant-id> 替换为目录(租户)ID
  7. 保存配置后,请在浏览器中导航至您站点上的/.auth/login/aad端点,并完成该流程以测试登录过程。
  8. 此时,您已成功地将配置复制过去,但现有的 Microsoft 帐户提供程序配置仍然存在。 在删除它之前,请确保应用程序的所有部分均通过登录链接等方式引用 Microsoft Entra 提供程序。 验证应用的所有部分是否按预期工作。
  9. 确认所有内容与 Microsoft Entra 提供程序正常工作后,您可以删除 Microsoft 帐户提供程序配置。

警告

可以通过修改 Microsoft Entra 应用注册 支持的帐户类型 来聚合这两个注册。 但此配置会强制向 Microsoft 帐户用户显示新的同意提示,并且这些用户的标识声明在结构上可能不同,由于正在使用新的应用 ID,sub 值会发生明显变化。 除非你完全了解此方法,否则不建议使用此方法。 应改为等待 V2 API 表面提供对两个注册的支持。

切换到 V2

完成上述步骤后,请转到 Azure 门户中的应用。 选择“ 身份验证”(预览版) 部分。

或者,可以对站点资源下的 config/authsettingsv2 资源发出 PUT 请求。 有效负载的架构与在“基于文件的配置”中捕获的架构相同。

将应用固定到特定身份验证运行时版本

启用身份验证/授权时,会将平台中间件注入 HTTP 请求管道,如功能概述中所述。 作为平台例常更新的一部分,此平台中间件会定期更新新功能和改进。 默认情况下,Web 或函数应用在此平台中间件的最新版本上运行。 这些自动更新始终向后兼容。 但在极少情况下,此自动更新会引入 Web 或函数应用的运行时问题,此时可以暂时回滚到以前的中间件版本。 本部分介绍如何暂时将应用固定到身份验证中间件的特定版本。

自动和手动版本更新

可以通过为应用配置 runtimeVersion 设置,将应用固定到平台中间件的特定版本。 除非你选择将应用显式固定到特定版本,否则你的应用始终在最新版本上运行。 同时支持多个版本。 如果固定到不再受支持的无效版本,应用会改用最新版本。 若要始终运行最新版本,请设置为 runtimeVersion~1

查看和更新当前运行时版本

可以更改应用使用的运行时版本。 重启应用后,新的运行时版本应生效。

查看当前运行时版本

可以使用 Azure CLI 或通过应用中的内置版本 HTTP 终结点之一来查看平台身份验证中间件的当前版本。

通过 Azure CLI

使用 Azure CLI,使用 az webapp auth show 命令查看当前中间件版本。

az webapp auth show --name <my_app_name> \
--resource-group <my_resource_group>

在此代码中,使用你的应用的名称替换 <my_app_name>。 将 <my_resource_group> 替换为您的应用的资源组名称。

你将在 CLI 输出中看到 runtimeVersion 字段。 它类似于以下示例输出,为了清楚起见,该输出将被截断:

{
  "additionalLoginParams": null,
  "allowedAudiences": null,
    ...
  "runtimeVersion": "1.3.2",
    ...
}
通过版本终结点

还可以在应用上命中 /.auth/version 终结点,以查看应用正在运行的当前中间件版本。 输出将类似于以下内容:

{
"version": "1.3.2"
}

更新当前运行时版本

使用 Azure CLI,可以使用 runtimeVersion 命令更新应用中的设置:

az webapp auth update --name <my_app_name> \
--resource-group <my_resource_group> \
--runtime-version <version>

<my_app_name> 替换为你的应用的名称。 将 <my_resource_group> 替换为应用资源组的名称。 替换 <version> 为 1.x 运行时的有效版本,或者使用 ~1 以获得最新版本。 若要确定 Azure Functions 应锁定到的版本,请参阅 Azure Functions 运行时版本概述

可以选择先前代码示例中的“打开 Cloud Shell”,以从 Azure Cloud Shell 运行此命令。 还可以在本地使用 Azure CLI 在运行 az login 登录后运行此命令。

后续步骤