Compartir vía

Información general sobre autenticación y autorización de back-end

  • Artículo

La carga de trabajo de muestra para desarrolladores de Fabric tiene los siguientes flujos de autenticación en el back-end.

Autenticación y autorización de solicitudes de Fabric para la carga de trabajo

Estructura del encabezado de autorización

El encabezado de autorización usa un formato de token específico:

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

Este formato incluye dos tokens distintos:

  • subjectToken: un token delegado que representa al usuario en cuyo nombre se realiza la operación.
  • appToken: un token específico para la aplicación Fabric.

La lógica detrás del uso de un encabezado de doble token es triple:

  • Validación: la carga de trabajo puede verificar que la solicitud se originó en Fabric mediante la validación de appToken.

  • Contexto de usuario: subjectToken proporciona un contexto de usuario para la acción que se realiza.

  • Comunicación entre servicios: la carga de trabajo puede adquirir un token delegado (OBO) mediante subjectToken, lo que le permite llamar a otros servicios con un token de usuario.

Autenticación

Las principales comprobaciones de autenticación que se realizan para SubjectAndAppToken son:

  • La validación y el análisis del valor del encabezado de autorización se realiza en el método AuthenticateControlPlaneCall. El token debe comenzar por el prefijo "SubjectAndAppToken1.0" e incluir dos tokens: subjectToken y appToken.

  • Validación de las propiedades del token de Entra: tanto subjectToken como appToken se validan para comprobar las propiedades comunes del token de Microsoft Entra en el método ValidateAadTokenCommon. Estas propiedades incluyen la firma del token, la duración del token, el público del token (público de la aplicación de carga de trabajo), la versión del token (1.0) y el emisor.

  • Validación de las propiedades appToken: appToken no debe tener ninguna notificación de scp, pero sí una notificación de idtyp con aplicación como valor. También se comprueba esa notificación de tid en el id. de inquilino del publicador de la carga de trabajo.

    Notificaciones de appToken de muestra:

    {
"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"
}

  • Validación de las propiedades subjectToken: asegúrese de que subjectToken incluye una notificación de scp con el ámbito FabricWorkloadControl, de que no haya ninguna notificación de idtyp presente en el token y de que tiene el mismo appid que en appToken.

    Notificaciones de subjectToken de muestra:

    {
"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"
}

Consulte IAuthenticationService.

Nota:

Todas las validaciones del código de ejemplo son para tokens de la versión 1.0.

Autorización

Una vez confirmada que la solicitud se origina en el servicio de Fabric (a través de appToken), Fabric comprobó que el usuario tiene los permisos necesarios para realizar la acción, en función de los metadatos de permisos de Fabric.

Autenticación y autorización de solicitudes de carga de trabajo de Fabric

Solicitudes de control de la carga de trabajo

Las API de control de la carga de trabajo son API especiales de Fabric que admiten cargas de trabajo con administración del ciclo de vida de los elementos de Fabric. Estas API usan el mismo formato de encabezado de autorización SubjectAndAppToken1.0.

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

Las llamadas procedentes de la carga de trabajo incluyen los siguientes tokens:

  • subjectToken: un token delegado por el usuario (obtenido a través del flujo OBO) que representa al usuario en cuyo nombre se realiza la operación. Fabric verifica que el usuario tenga los permisos exigidos para realizar la acción necesaria.

  • appToken: un token específico para la aplicación de carga de trabajo. Fabric comprueba que este token de la aplicación de Microsoft Entra de la carga de trabajo a la que pertenece el elemento de Fabric correspondiente y que se encuentra en el inquilino del publicador de la carga de trabajo.

Consulte el método ValidatePermissions en AuthorizationHandler.

API públicas

Para llamar a las API públicas de Fabric, la carga de trabajo debe adquirir un token OBO estándar de Microsoft Entra con los alcances de API relevantes y pasarlo como un token portador en el encabezado de autorización de la solicitud.

Consulte FabricExtensionController.

Autenticación y autorización de solicitudes del FE al BE de la carga de trabajo

Encabezado de autorización

El encabezado de autorización de una solicitud enviada desde el FE al BE de la carga de trabajo usa un token de portador estándar.

Autenticación

El método AuthenticateControlPlaneCall de la carga de trabajo BE es responsable de validar el token. Estas son las principales comprobaciones que se realizan:

  • Duración del token: garantiza que el token está dentro de su período de utilización válido.

  • Firma: verifica la autenticidad del token.

  • Público: verifica que la audiencia del token coincida con la carga de trabajo de la aplicación Microsoft Entra.

  • Elimsor: valida el emisor del token.

  • Ámbitos permitidos: valida los ámbitos a los que el token tiene permitido el acceso.

La autorización se logra invocando el método ValidatePermissions. Este método llama a la API resolvePermissions en el punto de conexión de control de la carga de trabajo de Fabric para el elemento de Fabric pertinente y verifica que el usuario tiene los permisos necesarios para la operación.

Operaciones de larga duración: token de actualización

La autorización se logra invocando el método ValidatePermissions. Este método llama a la API resolvePermissions en el punto de conexión de control de la carga de trabajo de Fabric para el elemento de Fabric pertinente y verifica que el usuario tiene los permisos necesarios para la operación.

Si las cargas de trabajo incluyen operaciones de larga duración, por ejemplo, como parte de JobScheduler, es posible que se produzca una situación en la que la duración del token no sea suficiente. Para obtener más información sobre cómo autenticar procesos de ejecución prolongada, consulte Procesos OBO de ejecución prolongada.