Administración de las versiones de la API y el entorno de ejecución de la autenticación de App Service

En este artículo se describe cómo personalizar la API y las versiones en tiempo de ejecución de la autenticación y autorización integradas en App Service.

Hay dos versiones de la API de administración para la autenticación de App Service. La versión V2 es necesaria para la experiencia de autenticación en Azure Portal. Una aplicación que ya usa la API V1 puede actualizar a la versión V2 después de realizar algunos cambios. En concreto, la configuración de secretos debe moverse a una configuración de la aplicación con espacios fijos. Puede mover la configuración de secretos automáticamente desde la sección Autenticación de la aplicación en el portal.

Actualización de la versión de configuración

Advertencia

La migración a V2 deshabilita la administración de la funcionalidad de autenticación/autorización de App Service para su aplicación a través de algunos clientes, como sus experiencias existentes en el portal de Azure, la CLI de Azure y Azure PowerShell. Esta migración no se puede revertir.

La API V2 no admite la creación ni edición de una cuenta Microsoft como proveedor distinto, como lo hace V1. En su lugar, usa la plataforma de identidad convergente de Microsoft para iniciar sesión de los usuarios con cuentas microsoft Entra y personales de Microsoft. Al cambiar a la API V2, la configuración de Microsoft Entra V1 se usa para configurar el proveedor de la plataforma de identidad de Microsoft. El proveedor de cuentas de Microsoft V1 se mantiene en el proceso de migración y sigue funcionando con normalidad, pero debería pasar al modelo de plataforma de identidad de Microsoft más reciente. Para obtener más información, vea Cambiar una configuración a un proveedor de Microsoft Entra.

El proceso de migración automatizada mueve los secretos del proveedor a la configuración de la aplicación y, a continuación, convierte el resto de la configuración en el nuevo formato. Para usar la migración automática:

  1. Vaya a la aplicación en el portal y seleccione Configuración>autenticación en el panel izquierdo.
  2. Si la aplicación está configurada con el modelo V1, verá un botón Actualizar .
  3. Seleccione el botón Actualizar. Revise la descripción del mensaje de confirmación. Si está listo para realizar la migración, haga clic en Actualizar en el mensaje.

Administración manual de la migración

Los pasos siguientes le permiten migrar manualmente una aplicación a la API V2 si no desea usar la versión automática descrita anteriormente.

Traslado de secretos a la configuración de la aplicación

Para mover los secretos del proveedor de identidades a la configuración de la aplicación, complete estos pasos.

  1. Obtenga la configuración existente mediante la API V1:

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

    En la carga JSON resultante, anote el valor secreto que se usa para cada proveedor que ha configurado:

    • Microsoft Entra: clientSecret
    • Google: googleClientSecret
    • Facebook: facebookAppSecret
    • X: twitterConsumerSecret
    • Cuenta de Microsoft: microsoftAccountClientSecret

    Importante

    Los valores de secreto son credenciales de seguridad importantes y deben administrarse con cuidado. No comparta estos valores ni los conserve en un equipo local.

  2. Cree la configuración de la aplicación con espacios fijos para cada valor de secreto. Puede elegir el nombre de cada configuración de aplicación. Su valor debe coincidir con lo que obtuvo en el paso anterior o hacer referencia a un secreto de Azure Key Vault que ha creado con ese valor.

    Para crear la configuración, puede usar Azure Portal o ejecutar una variación del siguiente comando para cada proveedor:

    # 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>

    Nota:

    La configuración de la aplicación para este ajuste debe marcarse como adherente al slot, lo que significa que no se moverá entre entornos durante una operación de intercambio de slots. Esta configuración es necesaria porque la configuración de autenticación está vinculada al entorno.

  3. Cree un nuevo archivo denominado JSON authsettings.json. Tome el resultado que recibió previamente y quite de él cada valor de secreto. Agregue la salida restante al archivo, asegurándose de no incluir secretos. En algunos casos, la configuración puede tener matrices que contengan cadenas vacías. Asegúrese de que microsoftAccountOAuthScopes no lo haga. Si lo hace, cambie el valor a null.

  4. Agregue una propiedad a authsettings.json que apunte al nombre de la configuración de la aplicación que creó anteriormente para cada proveedor:

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

    Un archivo de configuración después de esta operación podría ser similar al siguiente, en este caso solo configurado para el id. de Microsoft Entra:

    {
    "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. Envíe este archivo como la nueva configuración de autenticación y autorización para la aplicación:

    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. Compruebe que la aplicación sigue funcionando según lo previsto después de enviar el archivo.

  7. Elimine el archivo usado en los pasos anteriores.

Ha migrado la aplicación para almacenar los secretos del proveedor de identidades como configuración de la aplicación.

Cambiar una configuración a un proveedor de Microsoft Entra

Si la configuración existente contiene un proveedor de cuentas Microsoft y no contiene un proveedor de Microsoft Entra, puede cambiar la configuración al proveedor de Microsoft Entra y, a continuación, realizar la migración:

  1. Vaya a Registros de aplicaciones en Azure Portal y busque el registro asociado a su proveedor de cuentas Microsoft. Puede estar bajo el encabezado Aplicaciones de propiedad .
  2. Vaya a la página Autenticación (versión preliminar) del registro. En URI de redirección, debería ver una entrada que termina en /.auth/login/microsoftaccount/callback. Copie este URI.
  3. Agregue un nuevo URI que coincida con el que acaba de copiar, pero termine con /.auth/login/aad/callback. Este URI permite que la configuración de autenticación o autorización de App Service use el registro.
  4. Ve a tu aplicación en el portal. Seleccione Configuración>Autenticación.
  5. Recopile la configuración del proveedor de cuentas Microsoft.
  6. Configure el proveedor de Microsoft Entra mediante el modo de administración avanzada y proporcione los valores de identificador de cliente y secreto de cliente que recopiló en el paso anterior. Para la URL del emisor, use <authentication-endpoint>/<tenant-id>/v2.0. Reemplace <authentication-endpoint> por el punto de conexión de autenticación para su entorno en la nube (por ejemplo, "https://login.microsoftonline.com" para Microsoft Entra ID global). Reemplace <tenant-id> por su ID de directorio (inquilino).
  7. Después de guardar la configuración, pruebe el flujo de inicio de sesión; para ello, vaya en el /.auth/login/aad explorador al punto de conexión del sitio y complete el flujo de inicio de sesión.
  8. En este momento, ha copiado correctamente la configuración, pero la configuración del proveedor de cuentas de Microsoft existente permanece. Antes de quitarlo, asegúrese de que todas las partes de la aplicación hacen referencia al proveedor de Microsoft Entra a través de vínculos de inicio de sesión, etc. Compruebe que todas las partes de la aplicación funcionan según lo previsto.
  9. Después de validar que todo funciona con el proveedor de Microsoft Entra, puede quitar la configuración del proveedor de cuentas de Microsoft.

Advertencia

Es posible converger los dos registros modificando los tipos de cuenta admitidos para el registro de aplicaciones de Microsoft Entra. Sin embargo, esta configuración forzaría una nueva solicitud de consentimiento para los usuarios de la cuenta de Microsoft y las notificaciones de identidad de esos usuarios podrían ser diferentes en la estructura, sub especialmente cambiando los valores porque se usa un nuevo identificador de aplicación. No se recomienda este enfoque a menos que lo comprenda exhaustivamente. En su lugar, debe esperar a que se admitan los dos registros en la superficie de la API V2.

Cambiar a V2

Después de completar los pasos anteriores, vaya a la aplicación en Azure Portal. Seleccione la sección Autenticación (versión preliminar).

Como alternativa, puede realizar una solicitud PUT al recurso config/authsettingsv2 dentro del recurso del sitio. El esquema de la carga es el mismo que el capturado en la configuración basada en archivos.

Anclaje de la aplicación a una versión específica en tiempo de ejecución de autenticación

Al habilitar la autenticación y la autorización, el middleware de la plataforma se inserta en la canalización de solicitudes HTTP, tal y como se describe en la información general sobre las características. Este middleware de la plataforma se actualiza periódicamente con nuevas características y mejoras, como parte de las actualizaciones habituales de la plataforma. De forma predeterminada, la aplicación web o de funciones se ejecuta en la versión más reciente de este middleware de plataforma. Estas actualizaciones automáticas siempre son compatibles con versiones anteriores. Sin embargo, en el caso excepcional de que la actualización automática provoque algún problema en tiempo de ejecución a la aplicación web o de funciones, se puede revertir temporalmente a la versión anterior del middleware. En esta sección se explica cómo anclar temporalmente una aplicación a una versión específica del middleware de autenticación.

Actualizaciones de versiones automáticas y manuales

Puedes anclar la aplicación a una versión específica del middleware de la plataforma configurando una runtimeVersion configuración para la aplicación. La aplicación siempre se ejecuta en la versión más reciente a menos que decida anclarla explícitamente a una versión específica. Hay algunas versiones que se admiten simultáneamente. Si anclas a una versión no válida que ya no se admite, la aplicación usa la versión más reciente en su lugar. Para ejecutar siempre la versión más reciente, establezca runtimeVersion a ~1.

Visualización y actualización de la versión actual del entorno de ejecución

Puede cambiar la versión en tiempo de ejecución utilizada por la aplicación. La nueva versión en tiempo de ejecución debe surtir efecto después de reiniciar la aplicación.

Visualización de la versión actual del runtime

Puede ver la versión actual del middleware de autenticación de plataforma mediante la CLI de Azure o a través de uno de los puntos de conexión HTTP de la versión integrada en la aplicación.

Desde la CLI de Azure

Con la CLI de Azure, vea la versión actual del middleware con el comando az webapp auth show .

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

En el código, reemplace <my_app_name> por el nombre de la aplicación. Reemplace por <my_resource_group> el nombre del grupo de recursos de la aplicación.

Verá el campo runtimeVersion en la salida de la CLI. Se parece a la siguiente salida de ejemplo, que se trunca para mayor claridad:

{
  "additionalLoginParams": null,
  "allowedAudiences": null,
    ...
  "runtimeVersion": "1.3.2",
    ...
}
En el punto de conexión de la versión

También puede consultar el punto de conexión /.auth/version en una aplicación para ver la versión actual del middleware que está utilizando la aplicación. La salida tendrá una apariencia parecida a la siguiente:

{
"version": "1.3.2"
}

Actualización de la versión de tiempo de ejecución

Con la CLI de Azure, puede actualizar la runtimeVersion configuración en una aplicación mediante el comando az webapp auth update :

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

Reemplace <my_app_name> por el nombre de la aplicación. Reemplace por <my_resource_group> el nombre del grupo de recursos de la aplicación. Reemplace por <version> una versión válida de 1.x runtime o use ~1 para la versión más reciente. Para determinar la versión a la que se va a anclar para Azure Functions, consulte Introducción a las versiones en tiempo de ejecución de Azure Functions.

Para ejecutar este comando desde Azure Cloud Shell , seleccione Abrir Cloud Shell en el ejemplo de código anterior. También puede usar la CLI de Azure localmente para ejecutar este comando después de ejecutar az login para iniciar sesión.

Paso siguiente

Tutorial: Autenticación y autorización de usuarios de un extremo a otro

  • Last updated on