Partilhar via


Proteja fluxos de trabalho de agentes de conversação com Autenticação Fácil (Autenticação do Serviço de Aplicativo) nos Aplicativos Lógicos do Azure (Visualização)

Aplica-se a: Aplicativos Lógicos do Azure (Padrão)

Importante

Esta funcionalidade está em pré-visualização e está sujeita aos Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure.

Os fluxos de trabalho do agente expandem as opções de integração porque podem trocar mensagens com chamadores mais diversos, como pessoas, agentes, servidores e clientes MCP (Model Context Protocol), agentes de ferramentas e serviços externos. Enquanto os fluxos de trabalho não agentes interagem com um conjunto pequeno, conhecido e fixo de chamadores, os chamadores agentes podem vir de redes dinâmicas, desconhecidas e não confiáveis. Como resultado, você deve autenticar e impor permissões para cada chamador.

Para ajudar a proteger os fluxos de trabalho do agente de conversação em produção, configure o Easy Auth para autenticar e autorizar chamadores ou pessoas que desejam interagir com seu agente de conversação. O Easy Auth, também conhecido como Autenticação do Serviço de Aplicativo, fornece os seguintes recursos para você usar:

  • Forneça uma identidade validada para cada solicitação do chamador.
  • Atribua conexões a cada usuário.
  • Impor políticas de Acesso Condicional.
  • Emita credenciais revogáveis.
  • Conceda permissões com base nos princípios de privilégios mínimos, funções e escopos.
  • Forneça um cliente de chat externo fora do portal do Azure para que as pessoas possam interagir com seu agente de conversação.

Essas medidas permitem autenticar e autorizar cada chamador em um nível refinado e revogar o acesso rapidamente quando necessário. Sem esses controles, você corre o risco de acesso não controlado, segredos vazados, como URLs e chaves de acesso de assinatura de acesso compartilhado (SAS), trilhas de auditoria fracas e outros riscos de segurança.

O Easy Auth funciona com o Microsoft Entra ID como uma camada de segurança separada para fornecer recursos internos de autenticação e autorização que atendem às suas necessidades. Com a imposição de segurança operando fora do seu fluxo de trabalho, você pode se concentrar mais no desenvolvimento da lógica de negócios. Essa separação de preocupações torna os fluxos de trabalho dos agentes mais simples e fáceis de criar, depurar, operar, monitorar, manter, governar e auditar.

A segurança do fluxo de trabalho não agente geralmente envolve SAS estática, segredos rotativos e controles de limite de rede, como restrições de acesso, listas de permissões de IP, tags de serviço, integração de rede virtual e pontos de extremidade privados. Com fluxos de trabalho de agentes, você projeta a autorização em torno de usuários finais, identidades gerenciadas, entidades de serviço e seus escopos e funções. Essa abordagem permite um alcance global mais seguro, mas ainda permite que as ações do fluxo de trabalho downstream respeitem as permissões refinadas.

Este guia mostra como criar um registro de aplicativo e, em seguida, configurar o Easy Auth para seu recurso de aplicativo lógico padrão, que pode conter fluxos de trabalho de agente e não agente.

Importante

O Easy Auth armazena informações de configuração nas definições subjacentes da aplicação lógica do recurso, por exemplo, WEBSITE_AUTH_ENABLED, WEBSITE_AUTH_DEFAULT_PROVIDER e MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Não edite manualmente essas configurações, a menos que você queira configurar a automação usando modelos ARM, modelos Bicep ou modelos Terraform.

Para obter mais informações, consulte os seguintes artigos:

Pré-requisitos

Crie um registo de aplicação

Para obter a melhor maneira de iniciar a configuração do Easy Auth, crie um novo registro de aplicativo no Microsoft Entra ID diretamente do recurso do aplicativo lógico. Se, em vez disso, tiver de reutilizar um registo de aplicação existente, tem de atualizar o registo da aplicação para funcionar de forma limpa com os clientes Easy Auth e Azure.

  1. No portal do Azure, abra seu recurso de aplicativo lógico padrão.

  2. No menu da barra lateral de recursos, em Configurações, selecione Autenticação.

  3. Na página Autenticação , selecione Adicionar provedor de identidade.

    A captura de tela mostra o aplicativo lógico padrão com a página Autenticação aberta.

    A página Autenticação agora mostra a guia Noções básicas para configurar o provedor de identidade.

  4. Na guia Noções básicas , para Provedor de identidade, selecione Microsoft para Microsoft Entra ID.

  5. Na seção Registro de aplicativo , para Tipo de registro de aplicativo, selecione (Recomendado para agentes de conversação) Criar novo registro de aplicativo, que mostra as opções correspondentes para essa seleção.

  6. Forneça um nome de exibição exclusivo para o registro do seu aplicativo, por exemplo: agent-logic-app-reg-prod

  7. Em Identidade gerenciada atribuída pelo usuário, selecione Criar nova identidade gerenciada atribuída pelo usuário.

    Você pode criar uma nova identidade fornecendo um nome ou selecionando uma identidade existente.

  8. Em Tipos de conta suportados, selecione Locatário atual - Locatário único , a menos que queira aceitar intencionalmente outros locatários.

    A configuração de locatário único refere-se apenas a contas no diretório atual da organização. Assim, todas as contas de usuário e convidado neste diretório podem usar seu aplicativo ou API. Por exemplo, se o público-alvo for interno à sua organização, use essa configuração.

    O exemplo a seguir mostra como um registro de aplicativo pode parecer:

    A captura de tela mostra as informações básicas de registro do aplicativo.

    Importante

    A menos que você tenha políticas explícitas de governança e Acesso Condicional configuradas, não escolha Qualquer diretório do Microsoft Entra - Multilocatário.

    Para obter mais informações, consulte os seguintes artigos:

  9. Em Verificações adicionais, selecione os seguintes valores, se ainda não estiver selecionado:

    Configuração Valor
    Requisito do aplicativo cliente Permitir solicitações somente a partir deste aplicativo em si
    Requisito de identidade Permitir solicitações de identidades específicas
    Identidades permitidas Aparece apenas com a opção Permitir solicitações de identidades específicas selecionada.

    O valor pré-preenchido padrão é o ID do objeto que representa o usuário atual, ou seja, você mesmo. Você pode atualizar esse valor das seguintes maneiras:

    - Inclua IDs de objeto para outros desenvolvedores ou usuários.
    - Use declarações de grupo para incluir um grupo específico, em vez de IDs de objeto individuais.
    - Selecione um registro de aplicativo existente para seu recurso de aplicativo lógico. Se você fizer isso, certifique-se de atualizar o registro do aplicativo para funcionar corretamente com o Easy Auth.

    Para obter mais informações, consulte Usar uma política de autorização interna.
    Requisito do inquilino Permitir solicitações somente do locatário emissor
  10. Ignore a seção Caminhos excluídos .

  11. Opcionalmente, em Configurações de autenticação do Serviço de Aplicativo, revise as seguintes configurações e execute as ações apropriadas:

    Configuração Ação
    Restringir o acesso A menos que você planeje permitir alguns pontos de extremidade autenticados, selecione Exigir autenticação para bloquear todas as solicitações anônimas.
    Pedidos não autenticados Consoante os chamadores sejam baseados em agente ou não, selecione HTTP 302 Redirecionamento encontrado: recomendado para agentes.
  12. Quando terminar, selecione Adicionar para concluir a adição do provedor de identidade.

    O Azure cria o registro do aplicativo, atualiza as configurações do aplicativo e habilita o tempo de execução da Autenticação Fácil. Quando o Azure terminar, a página Autenticação do aplicativo lógico lista a Microsoft como um provedor de identidade. Clientes e chamadores agora devem autenticar suas identidades. Seu aplicativo lógico rejeita clientes e chamadores não autenticados conforme pretendido e emite uma resposta de redirecionamento 302 Found ou uma resposta 401 Unauthorized quando as solicitações não incluem tokens válidos.

    Depois de concluir a criação do registo da aplicação, mantenha a configuração da aplicação lógica o mais simples possível até poder confirmar que a autenticação funciona conforme o esperado. Mais tarde, você pode adicionar escopos de permissão ou funções de aplicativo que deseja impor acessando as seguintes páginas no recurso de registro do aplicativo:

    • Na barra lateral de registro do aplicativo, em Gerenciar, selecione Expor uma API para adicionar um escopo de permissão. Para obter mais informações, consulte Adicionar um escopo.

    • Na barra lateral de registro do aplicativo, em Gerenciar, selecione Funções do aplicativo para atribuir uma função de aplicativo. Para obter mais informações, consulte Atribuir função de aplicativo.

    Em alternativa, pode rever os passos correspondentes na secção seguinte, Atualizar um registo de aplicação existente.

  13. Para verificar se o registro do aplicativo está configurado corretamente, consulte Testar e validar a configuração do Easy Auth.

Atualizar um registo de aplicação existente

Se você precisar reutilizar um registro de aplicativo existente que é compartilhado com outra API ou um protótipo anterior, siga estas etapas para revisar e ajustar as configurações especificadas para que o registro do aplicativo possa funcionar corretamente com clientes Easy Auth e agente.

  1. Na caixa de pesquisa do portal do Azure, localize e selecione Microsoft Entra ID.

  2. No menu da barra lateral, em Gerir, selecione Registos de aplicações e, em seguida, localize e selecione o registo da sua aplicação.

  3. No menu da barra lateral de registro do aplicativo, expanda Gerenciar.

  4. Em Gerir, selecione Propriedades de marca & e confirme se a definição URL da página inicial especifica o URL do Web site da aplicação lógica.

    Observação

    O URL da página inicial é opcional para APIs somente de back-end ou agente. Defina esse valor somente se os usuários finais precisarem de uma página de destino ou documentação. Os redirecionamentos de token não usam esse valor.

  5. Em Gerir, selecione Autenticação.

    1. Em Configurações da plataforma, verifique se a entrada da Web existe.

    2. Na entrada Web , em Redirecionar URIs, localize o URI de retorno de chamada Easy Auth (Autenticação do Serviço de Aplicativo) pré-preenchido, que segue esta sintaxe:

      https://<logic-app-name>.azurewebsites.net/.auth/login/aad/callback

      Mantenha esse valor padrão, a menos que seu cenário precise que você exponha IDs de aplicativo de API personalizadas. Este URI de retorno de chamada é o destinatário padrão dos tokens de acesso e especifica quais recursos podem aceitar tokens de acesso de clientes que desejam acessar esses recursos.

      O objetivo por trás de um público de token permitido é honrar apenas as solicitações que apresentam tokens válidos para esses recursos. Uma solicitação de token de acesso envolve duas partes: o cliente que solicita o token e o recurso que aceita o token. O destinatário é conhecido como o token "audiência", que é o seu aplicativo lógico neste caso.

      Para obter mais informações, consulte O que é um URI de redirecionamento?

    3. Se o Azure não preencher previamente a configuração de URIs de redirecionamento , insira manualmente o URI com o nome do aplicativo lógico, por exemplo:

      https://my-chatbox-logic-app.azurewebsites.net/.auth/login/aad/callback

      Importante

      Não use URIs de redirecionamento personalizados, a menos que esteja hospedando um front-end interativo.

    4. Desconsidere a definição da URL de logout do front-channel.

    5. Para Concessão implícita e fluxos híbridos, selecione as duas opções a seguir:

      • Tokens de acesso (usados para fluxos implícitos)
      • Tokens de ID (usados para fluxos implícitos e híbridos)

      Para obter mais informações, veja a seguinte documentação:

    6. Em Tipos de conta suportados, selecione a opção que corresponde às necessidades da sua empresa.

      Na maioria dos casos, escolha Contas somente neste diretório organizacional (somente Microsoft - Locatário único). Para a opção multilocatário, verifique se você tem a governança explícita do Azure e as políticas de Acesso Condicional configuradas. Para obter mais informações sobre essas opções, consulte Diferenças de validação por tipos de conta suportados.

    7. Em Configurações avançadas, para Permitir fluxos de clientes públicos, mantenha a configuração Não para habilitar os fluxos móveis e de desktop especificados.

      A exceção ocorre quando clientes nativos e públicos devem evitar o fluxo de credenciais de senha do proprietário do recurso (ROPC) usando um dispositivo ou código de autenticação.

    8. Quando terminar, selecione Guardar.

  6. Em Gerenciar, selecione Certificados & segredos. Na guia Credenciais federadas , configure uma nova identidade gerenciada atribuída pelo usuário que tenha acesso ao aplicativo lógico para que você possa usar a identidade gerenciada como uma credencial de identidade federada no registro do aplicativo.

    Se não tiver uma identidade gerida atribuída ao utilizador com acesso ao logic app, siga os seguintes passos:

    1. Crie uma identidade gerenciada atribuída pelo usuário.
    2. Adicione a identidade atribuída pelo usuário ao seu aplicativo lógico.
    3. Configure a identidade atribuída pelo usuário como uma credencial de identidade federada no registro do seu aplicativo.
  7. Opcionalmente, se você precisar configurar declarações , como funções, escopos, grupos de usuários ou XMS_CC, siga estas etapas:

    1. Em Gerenciar, selecione Configuração de token.

    2. Na seção Declarações opcionais , adicione suas reivindicações.

      Observação

      Para evitar o inchaço do token, configure verificações de função ou escopo, em vez de declarações de grupo grande.

  8. Em Gerenciar, selecione Permissões de API e siga estas etapas:

    1. Em Permissões configuradas, selecione Adicionar uma permissão.
    2. No painel Solicitar permissões da API , na guia APIs da Microsoft , localize e selecione Microsoft Graph.
    3. Para o tipo de permissões, selecione Permissões delegadas.
    4. Na caixa Selecionar permissões , digite User.Read.
    5. Na coluna Permissão , expanda Usuário e selecione a permissão Usuário.Ler .

    Para obter mais informações, consulte Adicionar permissões para acessar o Microsoft Graph.

  9. Opcionalmente, em Gerenciar, selecione Expor uma API, para que você possa definir e expor escopos de permissão.

    Para a configuração URI de ID de Aplicação, o URI pré-preenchido é um identificador exclusivo que representa o recurso da aplicação lógica como a audiência em tokens de acesso e utiliza o seguinte formato:

    api://<application-client-ID>

    Na seção Escopos definidos por esta API , se você quiser confiar apenas na validação de funções e público-alvo, não será necessário definir ou expor nenhum escopo de permissão. No entanto, se você quiser que os clientes do Azure solicitem permissões delegadas, defina esses escopos seguindo estas etapas:

    1. Selecione Adicionar um escopo e forneça as seguintes informações:

      Configuração Obrigatório Valor
      Nome do escopo Yes user_impersonation
      Quem pode consentir Yes Administradores e utilizadores
      Nome de exibição do consentimento do administrador Yes Rótulo ou nome para o escopo de permissão que a mensagem de consentimento apresenta quando os administradores de inquilinos fornecem consentimento para o escopo.

      Por exemplo:
      Lógica de acesso <ao nome do aplicativo>
      Definição de consentimento do administrador Yes Descrição detalhada do escopo de permissão que a tela de consentimento mostra quando os administradores de locatários expandem o escopo na tela de consentimento.

      Por exemplo:
      Permita que o aplicativo acesse <logic-app-name> em nome do usuário conectado.
      Nome de exibição do consentimento do usuário Não Nome opcional para o âmbito de permissão que o ecrã de consentimento mostra quando os utilizadores finais fornecem consentimento para este âmbito.

      Por exemplo:
      Lógica de acesso <ao nome do aplicativo>
      Definição de consentimento do utilizador Não Descrição detalhada opcional para o escopo de permissão que a tela de consentimento mostra quando os usuários finais expandem o escopo na tela de consentimento.

      Por exemplo:
      Permita que o aplicativo acesse <logic-app-name> em seu nome.
      State Yes Ativado
    2. Quando terminar, selecione Adicionar escopo.

    3. Na lista Escopos , revise as configurações de escopo atualizadas para confirmar se elas aparecem conforme o esperado.

  10. Quando terminar de atualizar o registro do aplicativo, vá para o recurso do aplicativo lógico padrão.

  11. Na barra lateral do aplicativo lógico, em Configurações, selecione Autenticação.

  12. Na página Autenticação , ao lado de Configurações de autenticação, selecione Editar para revisar as configurações. No painel Editar configurações de autenticação , confirme os seguintes valores:

Configuração Valor Description
Autenticação do Serviço de Aplicativo Ativado Seu aplicativo lógico é configurado e ativado com o Easy Auth.
Restringir o acesso Exigir autenticação Clientes e chamadores devem autenticar suas identidades.
Pedidos não autenticados Yes Seu aplicativo lógico rejeita clientes e chamadores não autenticados conforme pretendido e emite uma resposta de redirecionamento 302 Found ou uma resposta 401 Unauthorized quando as solicitações não incluem tokens válidos.

Teste e valide a configuração do Easy Auth

Depois de configurar o Easy Auth, a interface de chat interna na página de Chat do seu fluxo de trabalho no portal do Azure fica indisponível. Em vez disso, você deve interagir com seu agente de conversação usando o cliente de chat externo que está disponível fora do portal do Azure. Para confirmar se o Easy Auth funciona conforme o esperado, execute o teste no cliente de chat externo seguindo estas etapas:

  1. Na barra de ferramentas do designer ou na barra lateral do fluxo de trabalho, selecione Bate-papo.

    A interface de chat interna não aparece mais na página de bate-papo .

  2. Na seção Essentials , selecione o link URL do Cliente de Chat , que abre uma nova guia do navegador.

  3. No prompt de solicitação de permissões, forneça seu consentimento e aceite a solicitação.

    A captura de tela mostra o prompt de consentimento de solicitação de permissões.

    A página do navegador é atualizada e mostra a interface para o cliente de chat externo.

    Sugestão

    Você também pode incorporar o URL do cliente de bate-papo em um elemento HTML do iFrame que você pode usar com seu site onde deseja fornecer o cliente de bate-papo, por exemplo:

    <iframe src="https:/<logic-app-name>.azurewebsites.net/api/agentsChat/<workflow-name>/IFrame" title="<chat-client-name>"></iframe>

  4. Na interface de chat externo, inicie ou continue a interagir com o seu agente de conversação.

  5. Para rever o histórico de execução do fluxo de trabalho, siga estes passos:

    1. Retorne ao fluxo de trabalho no portal do Azure.

    2. Na barra lateral do fluxo de trabalho, em Ferramentas, selecione Histórico de execução e, em seguida, selecione a execução mais recente do fluxo de trabalho.

    3. Na visualização de monitoramento, confirme se o histórico de execução e os status da operação aparecem conforme o esperado.

Solucionar erros durante o teste de autenticação fácil

A tabela a seguir descreve problemas comuns que você pode encontrar ao configurar o Easy Auth, possíveis causas e ações que você pode tomar:

Problema ou erro Causa provável Ação
401 com invalid_token + error_description que faz referência ao público Existe uma incompatibilidade entre o público do token de acesso e os públicos de token permitidos especificados. Certifique-se de que o público-alvo do token de acesso e o público-alvo permitido do token correspondam.
403 Proibido Pode indicar que o fluxo de trabalho ou agente para a solicitação não foi encontrado. Verifique as ações em seu fluxo de trabalho para um problema de autorização.

Usar uma identidade no fluxo de trabalho

Quando o Easy Auth valida uma solicitação, o Easy Auth injeta dados de identidade em cabeçalhos de solicitação com base no provedor de identidade. Seu aplicativo lógico usa esses cabeçalhos para autenticar o chamador.

Para obter mais informações, consulte os seguintes artigos: