Erro AzureAD AADSTS7500525 usando plugin SAML

Olá!!

Estávamos com o plugin SAML funcionando com nosso AzureAD, mas ontem, após atualizarmos para o último commit, começamos a ver os seguintes erros quando os usuários tentam autenticar via SAML:

Sign in
Sorry, but we’re having trouble signing you in.

AADSTS7500525: There was an XML error in the SAML message at line 1, position 1. Verify that the XML content of the SAML messages conforms to the SAML protocol specifications.

Este link Azure AD SAML2 request rejected: AADSTS7500525 - Microsoft Q&A sugere que isso pode ser causado por “Compressed SAML Authentication Requests” que o AzureAD não suporta.

Os commits de dezembro têm muitas alterações no SAML (configuração via configurações do site, por exemplo), mas não consegui descobrir se houve alguma alteração relacionada às solicitações SAML que possa ter causado isso.

Configuração SAML (funcionando bem até a atualização):

## Saml plugin setting
  DISCOURSE_SAML_TARGET_URL: https://login.microsoftonline.com/<<nosso id de aplicativo>>/saml2
  DISCOURSE_SAML_CERT_FINGERPRINT: "<<nosso fingerprint>>"
  DISCOURSE_SAML_REQUEST_METHOD: POST
  #DISCOURSE_SAML_FULL_SCREEN_LOGIN: true
  DISCOURSE_SAML_CERT: "-----BEGIN CERTIFICATE-----
<<Nosso payload de certificado>>
-----END CERTIFICATE-----"
  DISCOURSE_SAML_SYNC_GROUPS: true
  DISCOURSE_SAML_GROUPS_ATTRIBUTE: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
  DISCOURSE_SAML_GROUPS_FULLSYNC: true

Como posso habilitar a depuração de autenticação para obter mais informações sobre isso?

1 curtida

Lamento saber que você está tendo problemas! Você está certo de que tenho feito muita refatoração no plugin SAML nas últimas semanas, então pode estar relacionado.

Quando isso acontece? Quando os usuários iniciam o login? Ou quando eles retornam ao Discourse?

Alguma chance de você compartilhar o URL do seu site aqui, ou por mensagem privada?

1 curtida

Isso acontece sempre que um usuário precisa fazer login (uma sessão expirou ou um novo usuário tenta fazer login).

Começou a acontecer depois que atualizei para a revisão 9334abe249 (estava na 959923d3cf antes).

Desculpe, mas nosso fórum é hospedado internamente em uma conta privada da AWS, então você não poderá acessá-lo de fora de nossa rede.

O erro aparece em algum lugar? Nos logs do Discourse? Na tela do usuário? No Azure?

Você poderia compartilhar algumas capturas de tela?

1 curtida

Também tentei encontrar algo nos logs do Discourse, mas como o erro ocorre no lado do Azure, não encontrei nenhuma mensagem de erro lá.

No production.log, o processo de login para aqui (provavelmente esperando um retorno do Azure):

Processing by StaticController#show as HTML
Parameters: {“id”=>“login”}
Rendered static/login.html.erb (Duration: 17.5ms | Allocations: 1440)
Completed 200 OK in 19ms (Views: 18.3ms | ActiveRecord: 0.0ms | Allocations: 2104)
Started GET “/session/csrf” for <> at 2021-12-14 18:28:16 -0300
Processing by SessionController#csrf as JSON
Completed 200 OK in 1ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 337)
Started POST “/auth/saml” for <> at 2021-12-14 18:28:16 -0300
(saml) Setup endpoint detected, running now.
(saml) Request phase initiated.

A equipe responsável pelo Azure está tentando obter o XML que estão recebendo, então talvez possamos ver algo “diferente” nele. Avisarei quando eles me enviarem.

1 curtida

O erro ocorre após o usuário clicar no botão de login.
Em seguida, ele é redirecionado para a página de login do Azure com o seguinte erro:

Receio que seja difícil entender o que está acontecendo aqui sem acesso ao site.

O próximo passo seria tentar obter o XML que está sendo recebido pelo Azure e descobrir o que há de errado com ele. Você deve ser capaz de fazer isso verificando a carga útil nas ferramentas do desenvolvedor do navegador e, em seguida, decodificando-a usando uma ferramenta como esta.

2 curtidas

Ótimo!
O retorno da requisição é um código http 400:

Request URL: https://login.microsoftonline.com/APP_ID/saml2
Request method: POST
Status code: 400 Bad Request
Remote address: 20.190.173.144:443
Referrer policy: strict-origin-when-cross-origin

O SAMLRequest inflado é (alguns IDs ocultos por privacidade):

<samlp:AuthnRequest AssertionConsumerServiceURL='https://INTERNAL_URL/auth/saml/callback' Destination='https://login.microsoftonline.com/APP_ID/saml2' ID='_11111111-1111-1111-1111-111111111111' IssueInstant='2021-12-14T22:33:29Z' Version='2.0' xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion' xmlns:samlp='urn:oasis:names:tc:SAML:2.0:protocol'><saml:Issuer>https://INTERNAL_URL</saml:Issuer></samlp:AuthnRequest>

Uma coisa que notei ao comparar minha solicitação com o exemplo em Single sign-on SAML protocol - Microsoft identity platform | Microsoft Learn é que em nosso AuthnRequest não temos o parâmetro

xmlns="urn:oasis:names:tc:SAML:2.0:metadata"

Parece que minha refatoração recente adicionou inadvertidamente compressão para o SAML POST binding. Reverti essa mudança de comportamento em FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub

Você pode, por favor, tentar atualizar o plugin SAML e ver se as coisas estão funcionando melhor?

4 curtidas

Olá David,

Após atualizar para FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub a autenticação SAML voltou ao normal aqui.

Obrigado pela ajuda e por todo o trabalho no plugin!

1 curtida

Este tópico foi fechado automaticamente após 20 horas. Novas respostas não são mais permitidas.