AWS Client VPN SAML e Google Workspace: a lacuna do callback

A página app_not_configured_for_user vem do Google Workspace e aparece antes de um único pacote de túnel ser negociado. Essa ordem é todo o diagnóstico. Reinstalar o cliente, editar o perfil ou verificar as rotas não consegue limpar uma página que o endpoint da VPN ainda não viu. A etapa que falha é uma passagem no navegador entre o provedor de identidade e um ouvinte na própria máquina do usuário, e nessa passagem há exatamente três coisas que vale a pena verificar.

Leia a página como uma declaração do provedor de identidade

O Google devolve isto quando a aplicação SAML não está habilitada para a conta que iniciou sessão. A aplicação pode estar desligada, o usuário pode estar fora da unidade organizacional ou do grupo atribuído, ou as definições do provedor de serviço podem não corresponder ao que o pedido exigia.

Nada disso é um problema de certificado, rota ou túnel, embora o usuário o tenha notado no cliente da VPN.

Os dois valores que o cliente aceitará

O AWS Client VPN realiza uma troca SAML iniciada pelo provedor de serviço, por isso o cliente abre um navegador, o usuário autentica-se e o provedor envia uma asserção assinada de volta para um URL de Assertion Consumer Service. Para o cliente de ambiente de trabalho fornecido pela AWS, esse URL é um ouvinte em loopback, normalmente a porta 35001, e o público esperado é o identificador de entidade da aplicação SAML do Client VPN, não a entidade de início de sessão da consola da AWS.

Ambos os valores têm de coincidir com o que o cliente espera: onde a asserção é publicada e a quem se dirige. Uma configuração copiada de uma aplicação SSO da consola pode parecer perfeitamente plausível e ainda assim apontar para o par errado.

Retire ambos os valores dos requisitos do Client VPN SAML, não de um guia genérico de início de sessão único da AWS. A entidade SSO da consola parece suficientemente semelhante para ser tentadora. É outra aplicação com outro público, e o cliente rejeita a asserção sem se explicar. Copie o par uma vez e guarde-o ao lado do perfil.

O Google não aceitará o callback HTTP simples

A consola de administração exige um URL ACS HTTPS, e o callback do cliente é HTTP simples em loopback. Esse valor não pode sequer ser escrito na configuração da aplicação Workspace, e é por isso que algumas equipas tentam um proxy inverso que termina TLS e encaminha para o ouvinte local. Isso não corrige a incoerência: o navegador vê uma origem, o cliente anuncia outra, e a resposta devolvida pode chegar ao destino errado.

A disposição que funciona é um provedor de identidade intermediário. A aplicação SAML no intermediário recebe o callback loopback e o público da AWS, e o intermediário federa a conta Workspace para cima. A regra HTTPS da Google continua satisfeita, e a asserção que chega ao cliente ainda nomeia o endereço e o público que espera.

Esse intermediário é uma dependência administrativa que alguém tem de possuir, monitorizar e incluir na saída do funcionário. É também um segundo local onde uma falha se torna um erro de início de sessão. Orçamente-o antes de prometer o desenho. Se ninguém o assumir, a resposta honesta é que o cliente da AWS não pode usar o Workspace como o seu único provedor de identidade.

Atribuição e verificação em dois passos

Antes de redesenhar o que quer que seja, confirme que a aplicação está ativa para a unidade organizacional ou o grupo corretos, e que as aplicações SAML de terceiros têm os seus próprios controlos de atribuição, separados da lista de aplicações do lado da Google.

Verifique também se a conta tem a verificação em dois passos ativa. A Google pode exigi-la antes de uma aplicação SAML ficar utilizável por um usuário, e uma única resposta no fio original foi resolvida exatamente assim. É a coisa mais barata de excluir e a mais irritante de descobrir por último.

Verifique com uma sessão limpa

Depois de qualquer alteração, teste com um perfil de navegador novo e uma configuração de cliente limpa. As asserções em cache e as sessões reutilizadas escondem se a correção chegou.

Depois compare dois registos lado a lado: o evento de auditoria do provedor de identidade e o registo do cliente. Um início de sessão bem-sucedido sem túnel aponta de volta para o callback ou para o público. Um túnel ligado com um recurso inalcançável é um problema de encaminhamento ou de autorização e pertence a outro lugar por completo.

O que não alterar

Não remova auth-federate do perfil nem desative as verificações de certificados para passar a página. Ambos alteram o desenho da autenticação em vez do callback que falha, e ambos costumam quebrar na atualização seguinte do cliente.

Corrija antes a passagem, e deixe uma nota que nomeie o intermediário, o público e a porta de loopback. A próxima pessoa a ver a página vai precisar das três coisas.