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.
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 ?
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é ?
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é.
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.
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é) :