AzureAD error AADSTS7500525 using SAML plugin

[Bruno_Salazar (Bruno M V M Salazar)]

Hi!!

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.

This link Azure AD SAML2 request rejected: AADSTS7500525 - Microsoft Q&A suggests that this can be caused by “Compressed SAML Authentication Requests” which AzureAD doesn’t support.

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.

SAML config (working OK until the update):

## Saml plugin setting
  DISCOURSE_SAML_TARGET_URL: https://login.microsoftonline.com/<<our app id>>/saml2
  DISCOURSE_SAML_CERT_FINGERPRINT: "<<our fingerprint>>"
  DISCOURSE_SAML_REQUEST_METHOD: POST
  #DISCOURSE_SAML_FULL_SCREEN_LOGIN: true
  DISCOURSE_SAML_CERT: "-----BEGIN CERTIFICATE-----
<<Our cert payload>>
-----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

How can I enable the auth debug to get more info about this?

[david (David Taylor)]

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?

[Bruno_Salazar (Bruno M V M Salazar)]

This happens whenever a user needs to login (a session expired or a new user tries to login).

It started to happen after I updated to the revision 9334abe249 (was on 959923d3cf before)

Sorry but our forum is hosted internally in a private AWS account so you will not be able to access from outside our network.

[david (David Taylor)]

Where does the error appear? In the Discourse logs? On the user’s screen? In Azure?

Could you share some screenshots?

[Bruno_Salazar (Bruno M V M Salazar)]

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.

[Bruno_Salazar (Bruno M V M Salazar)]

@david

Where does the error appear? In the Discourse logs? On the user’s screen? In Azure?

Could you share some screenshots?

The error occours after the user click on the login button.
Then it gets redirected to the Azure login page with the following error:

[david (David Taylor)]

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

[Bruno_Salazar (Bruno M V M Salazar)]

Great!

The return of the request is a http code 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

The inflated SAMLRequest is (some IDs hidden for privacy):

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

[Bruno_Salazar (Bruno M V M Salazar)]

One thing that I’ve noticed comparing my request with the example at Azure Single Sign On SAML Protocol - Microsoft identity platform | Microsoft Docs is that in my AuthnRequest we don’t have the parameter

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

[david (David Taylor)]

@Bruno_Salazar

suggests that this can be caused by “Compressed SAML Authentication Requests” which AzureAD doesn’t support.

Looks like my recent refactoring inadvertently added compression for the SAML POST binding. I’ve reverted that behaviour change in FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub

Please can you try updating the SAML plugin, and then see whether things are working better?

[Bruno_Salazar (Bruno M V M Salazar)]

Hi David,

After updating to FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub the SAML auth is back to normal here.

Thank you for the help and all the work on the plugin!