Erreur AzureAD AADSTS7500525 avec le plugin SAML

Salut !!

Nous avions le plugin SAML qui fonctionnait avec notre AzureAD, mais hier, après avoir mis à jour vers le dernier commit, nous avons commencé à voir les erreurs suivantes lorsque les utilisateurs tentent de s’authentifier via SAML :

Connexion
Désolé, nous avons du mal à vous connecter.

AADSTS7500525 : Il y a eu une erreur XML dans le message SAML à la ligne 1, position 1. Vérifiez que le contenu XML des messages SAML est conforme aux spécifications du protocole SAML.

Ce lien Azure AD SAML2 request rejected: AADSTS7500525 - Microsoft Q&A suggère que cela peut être causé par des “requêtes d’authentification SAML compressées” que AzureAD ne prend pas en charge.

Les commits de décembre comportent de nombreux changements sur SAML (configuration via les paramètres du site, par exemple), mais je n’ai pas pu déterminer s’il y avait eu un changement lié aux requêtes SAML qui aurait pu en être la cause.

Configuration SAML (fonctionnait bien jusqu’à la mise à jour) :

## Paramètre du plugin Saml
  DISCOURSE_SAML_TARGET_URL: https://login.microsoftonline.com/<<notre id d'application>>/saml2
  DISCOURSE_SAML_CERT_FINGERPRINT: "<<notre empreinte>>"
  DISCOURSE_SAML_REQUEST_METHOD: POST
  #DISCOURSE_SAML_FULL_SCREEN_LOGIN: true
  DISCOURSE_SAML_CERT: "-----BEGIN CERTIFICATE-----
<<Notre charge utile de certificat>>
-----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

Comment puis-je activer le débogage d’authentification pour obtenir plus d’informations à ce sujet ?

1 « J'aime »

Désolé d’apprendre que vous rencontrez des problèmes ! Vous avez raison, j’ai beaucoup refactorisé le plugin SAML ces dernières semaines, donc cela pourrait être lié.

Quand cela se produit-il ? Lorsque les utilisateurs initient la connexion ? Ou lorsqu’ils sont renvoyés vers Discourse ?

Auriez-vous la possibilité de partager l’URL de votre site ici, ou par message privé ?

1 « J'aime »

Cela se produit chaque fois qu’un utilisateur doit se connecter (une session a expiré ou un nouvel utilisateur essaie de se connecter).

Cela a commencé à se produire après la mise à jour vers la révision 9334abe249 (j’étais sur 959923d3cf auparavant).

Désolé, mais notre forum est hébergé en interne dans un compte AWS privé, vous ne pourrez donc pas y accéder depuis l’extérieur de notre réseau.

L’erreur apparaît-elle dans les journaux Discourse ? Sur l’écran de l’utilisateur ? Dans Azure ?

Pourriez-vous partager des captures d’écran ?

1 « J'aime »

J’ai aussi essayé de trouver quelque chose dans les journaux de Discourse mais comme l’erreur se produit côté Azure, je n’y ai trouvé aucun message d’erreur.

Dans production.log, le processus de connexion s’arrête ici (probablement en attendant un retour d’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 <<IP>> 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 <<IP>> at 2021-12-14 18:28:16 -0300
(saml) Setup endpoint detected, running now.
(saml) Request phase initiated.

L’équipe responsable d’Azure essaie d’obtenir le XML qu’ils reçoivent, donc peut-être que nous pourrons voir quelque chose de “différent” dedans. Je vous tiendrai au courant quand ils me l’auront envoyé.

1 « J'aime »

L’erreur se produit après que l’utilisateur clique sur le bouton de connexion.
Ensuite, il est redirigé vers la page de connexion Azure avec l’erreur suivante :

Je crains qu’il soit difficile de comprendre ce qui se passe ici sans accès au site.

La prochaine étape consisterait à essayer d’obtenir le XML reçu par Azure et à déterminer ce qui ne va pas. Vous devriez pouvoir le faire en vérifiant la charge utile dans les outils de développement du navigateur, puis en la décodant à l’aide d’un outil tel que celui-ci.

2 « J'aime »

Super !
Le retour de la requête est un code http 400 :

URL de la requête : https://login.microsoftonline.com/APP_ID/saml2
Méthode de la requête : POST
Code d'état : 400 Bad Request
Adresse distante : 20.190.173.144:443
Politique de référent : strict-origin-when-cross-origin

Le SAMLRequest gonflé est (certains ID masqués pour la confidentialité) :

<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>

Une chose que j’ai remarquée en comparant ma requête avec l’exemple sur Single sign-on SAML protocol - Microsoft identity platform | Microsoft Learn est que dans ma requête AuthnRequest, nous n’avons pas le paramètre

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

Il semble que mon récent refactoring ait involontairement ajouté la compression pour la liaison SAML POST. J’ai annulé ce changement de comportement dans FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub

Pouvez-vous s’il vous plaît essayer de mettre à jour le plugin SAML, puis voir si les choses fonctionnent mieux ?

4 « J'aime »

Salut David,

Après la mise à jour vers FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub, l’authentification SAML est de retour à la normale ici.

Merci pour votre aide et tout le travail sur le plugin !

1 « J'aime »

Ce sujet a été automatiquement fermé après 20 heures. Les nouvelles réponses ne sont plus autorisées.