Partilhar via

Visão geral da autenticação e autorização de back-end

  • Artigo

O exemplo de carga de trabalho do desenvolvedor de malha tem os seguintes fluxos de autenticação no lado do back-end.

Autenticação e autorização de solicitações do Fabric para a carga de trabalho

Estrutura do cabeçalho de autorização

O cabeçalho de autorização usa um formato de token específico:

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

Este formato inclui dois tokens distintos:

  • subjectToken: Um token delegado que representa o usuário em nome do qual a operação está sendo executada.
  • appToken: Um token específico para o aplicativo Fabric.

A lógica por trás do uso de um cabeçalho dual-token é tripla:

  • Validação: a carga de trabalho pode verificar se a solicitação se originou do Fabric validando o appToken.

  • Contexto do usuário: fornece subjectToken um contexto de usuário para a ação que está sendo executada.

  • Comunicação entre serviços: a carga de trabalho pode adquirir um token OBO (On-Behalf-Of) usando o subjectToken, permitindo chamar outros serviços com um token de usuário.

Autenticação

As principais verificações de autenticação realizadas para o SubjectAndAppToken são:

  • A validação e a análise do valor do cabeçalho de autorização são feitas no método AuthenticateControlPlaneCall . O token deve começar com o prefixo "SubjectAndAppToken1.0" e incluir dois tokens - subjectToken e appToken.

  • Validação de propriedades de token Entra: Ambos subjectToken e appToken são validados para propriedades comuns de token do Microsoft Entra no método ValidateAadTokenCommon . Essas propriedades incluem assinatura de token, tempo de vida do token, audiência de token (audiência do aplicativo de carga de trabalho) e versão do token (1.0) e emissor.

  • Validação de propriedades appToken: O appToken não deve ter uma scp declaração, mas deve ter uma idtyp declaração com app como o valor. Também verificamos essa tid declaração no ID do locatário do editor de carga de trabalho.

    Exemplos de declarações 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"
}

  • validação de propriedades subjectToken: certifique-se de que o subjectToken inclua uma scp declaração com o FabricWorkloadControl escopo, que não haja nenhuma idtyp declaração presente no token e que ele tenha o mesmo appid que no appToken.

    Exemplos de declarações 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"
}

Consulte IAuthenticationService.

Nota

Todas as validações em nosso código de exemplo são para tokens da versão 1.0.

Autorização

Uma vez confirmado que a solicitação tem origem no serviço Fabric (por meio do ), o appTokenFabric verificou se o usuário tem as permissões necessárias para executar a ação, com base nos metadados de permissões do Fabric.

Autenticação e autorização de solicitações da carga de trabalho para o Fabric

Solicitações de controle de carga de trabalho

As APIs de controle de carga de trabalho são APIs de malha especiais que oferecem suporte a cargas de trabalho com o gerenciamento do ciclo de vida do item de malha. Essas APIs usam o mesmo formato de cabeçalho de autorização SubjectAndAppToken1.0.

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

As chamadas provenientes da carga de trabalho incluíam os seguintes tokens:

  • subjectToken: Um token delegado pelo usuário (obtido através do fluxo OBO) que representa o usuário em nome do qual a operação está sendo executada. A malha verifica se o usuário tem as permissões necessárias para executar a ação necessária.

  • appToken: Um token específico para o aplicativo de carga de trabalho. O Fabric verifica se esse token é do aplicativo Microsoft Entra da carga de trabalho à qual o item Fabric relevante pertence e que está no locatário do editor de carga de trabalho.

Consulte o ValidatePermissions método em AuthorizationHandler.

APIs públicos

Para chamar APIs de malha públicas, a carga de trabalho deve adquirir um token OBO padrão do Microsoft Entra com os escopos de API relevantes e passá-lo como um token de portador no cabeçalho de autorização da solicitação.

Consulte FabricExtensionController.

Autenticação e autorização de solicitações de carga de trabalho FE para carga de trabalho BE

Cabeçalho de autorização

O cabeçalho de autorização em uma solicitação enviada da carga de trabalho FE para a carga de trabalho BE usa um token de portador padrão.

Autenticação

O método AuthenticateControlPlaneCall na carga de trabalho BE é responsável pela validação do token. As principais verificações realizadas são:

  • Tempo de vida do token: garante que o token esteja dentro do período de uso válido.

  • Assinatura: verifica a autenticidade do token.

  • Público: verifica se o público do token corresponde à carga de trabalho do aplicativo Microsoft Entra.

  • Emissor: Valida o emissor do token.

  • Escopos permitidos: valida os escopos que o token tem permissão para acessar.

A autorização é obtida invocando o método ValidatePermissions . Esse método chama a resolvePermissions API no ponto de extremidade de controle de carga de trabalho de malha para o item de malha relevante e verifica se o usuário tem as permissões necessárias para a operação.

Operações de longa duração - atualizar Token

A autorização é obtida invocando o método ValidatePermissions . Esse método chama a resolvePermissions API no ponto de extremidade de controle de carga de trabalho de malha para o item de malha relevante e verifica se o usuário tem as permissões necessárias para a operação.

Se suas cargas de trabalho incluírem operações de longa duração, por exemplo, como parte do JobScheduler, você pode se deparar com uma situação em que o tempo de vida do Token não é suficiente. Para obter mais informações sobre como autenticar processos de longa execução, processos OBO de longa execução.