Ajustando o Easy Auth no Azure Logic App Standard via CI/CD

Problema: O impacto visível do Easy Auth no Management do Logic App

Ao habilitar o Easy Auth (o serviço nativo de autenticação e autorização do Azure App Service) em um Logic App Standard, é comum que times de engenharia se deparem com uma frustração técnica: o histórico de execuções da página de run details deixa de exibir os inputs e outputs das ações. O workflow executa corretamente, o usuário possui permissões no IAM, mas a visibilidade operacional é cortada. Este artigo desconstrói por que isso ocorre.

Como o Easy Auth impacta o runtime do Logic App?

O modelo de execução do Logic App Standard introduz uma camada de abstração. Cada request que chega ao serviço é primeiramente validada pela camada de App Service, antes de ser roteada para o runtime do Logic App. A lógica de autenticação opera em dois níveis, e o problema reside justamente na descontinuidade entre eles:

1. O runtime do Logic App utiliza um token SAS específico, gerado pelas chaves de acesso, para autenticar as requisições de leitura do histórico.
2. O portal do Azure, ao solicitar o carregamento dos payloads de entrada e saída, envia esse token SAS.
3. O App Service, ao processar a requisição e ter o parâmetro unauthenticatedClientAction configurado como Return401, não reconhece o token SAS e bloqueia a requisição antes que ela chegue ao runtime.

Como a solicitação é barrada na borda, o painel de histórico não consegue renderizar os dados.

Como garantir segurança sem sacrificar a visibilidade?

Existem duas estratégias para contornar essa falha de visibilidade sem abrir mão da segurança do seu endpoint:

1. Permitir requisições não autenticadas

Nesta abordagem, configuramos o Easy Auth para encaminhar todas as chamadas ao runtime. É importante notar: isso não torna seu workflow público. O runtime continuará validando a autenticação (via SAS ou AAD) para cada trigger. O App Service apenas deixa de ser o guardião exclusivo, permitindo que a camada do Logic App faça o arbitramento da segurança.

2. Excluir os caminhos de runtime (Recomendado)

Se a política de conformidade da sua empresa é rígida quanto à autenticação de borda, a solução é manter o Easy Auth, mas adicionar os caminhos /runtime/* à lista de excludedPaths. Dessa forma, o tráfego do histórico é ignorado pelo middleware e processado diretamente pelo runtime via SAS.

Implementação via CI/CD

Como o Portal do Azure limita a gestão de excludedPaths, a solução deve ser declarativa. O uso de Infrastructure as Code (IaC) é indispensável aqui:

Abordagem 1: ARM Template (Recurso authsettingsV2)

Adicione ao seu template ARM um recurso do tipo Microsoft.Web/sites/config configurado como authsettingsV2. O segredo está em definir a propriedade corretamente:

Copiar"globalValidation": {
  "requireAuthentication": true,
  "unauthenticatedClientAction": "Return401",
  "excludedPaths": ["/runtime/*"]
}

Abordagem 2: Step de pós-deployment via REST API

Para ambientes onde a infraestrutura já está provisionada ou o pipeline de auth está desconectado do pipeline de deploy, uma chamada à REST API authsettingsV2 após o deployment é a alternativa mais flexível. Isso permite injetar as configurações necessárias de forma pontual (environment-specific) conforme a necessidade de cada ambiente (Dev, Staging ou Prod).

Conclusão

A falha de visibilidade imediata após a aplicação do Easy Auth é um sintoma clássico de desalinhamento entre as camadas de segurança do Azure. Ao delegar (ou excluir) corretamente os caminhos de /runtime/*, mantemos a postura de segurança desejada sem sacrificar as capacidades de observability e depuração dos nossos fluxos de trabalho. A automação desses ajustes via pipeline é a única forma de garantir a consistência e auditabilidade em ambientes de produção.

Perguntas Frequentes

• O que causa o erro de carregamento nos logs do Logic App após ativar o Easy Auth?
  O Azure App Service bloqueia requisições autenticadas por token SAS (usadas para carregar o histórico) ao tentar validá-las indevidamente como tokens de Easy Auth na borda.

• É possível corrigir isso via interface do Azure?
  Não. O portal não oferece exposição ao parâmetro excludedPaths, sendo necessária a implementação via ARM, Bicep ou REST API.

• Adicionar /runtime/* na lista de exclusão compromete a segurança do workflow?
  Não. As chamadas que chegam ao seu Logic App ainda sofrerão a validação correta de segurança (como tokens de acesso específicos ou Azure AD) dentro do próprio runtime, garantindo que apenas acessos autorizados sejam processados.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.