We had the SAML plugin working with our AzureAD, but yesterday after we upgraded to the last commit, we started seeing the following errors when users try to authenticate 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.
December commits have lots of changes on SAML (configuration via site settings, for example), but I was unable to figure out if there was some change related to SAML requests that may have caused this.
Sorry to hear you’re having issues! You’re right that I’ve been doing a lot of refactoring on the SAML plugin in the last few weeks, so it could be related.
When does this happen? When users initiate login? Or when they are returned to Discourse?
Any chance you could share your site URL here, or via PM?
I also tried to find something on discourse’s logs but since the error occours on the Azure side, didn’t find any error message there.
On production.log the login process stops here (probably waiting a return from 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.
The team responsible for azure is trying to get the XML they are receiving so maybe we are able see something “different” on it. I’ll let you know when they send me.
I’m afraid it’s difficult to work out what’s happening here without access to the site.
The next step would be to try and obtain the XML which is being received by Azure, and work out what’s wrong with it. You should be able to do that by checking the payload in the browser’s Developer tools, and then decoding it using a tool like this