Errore AzureAD AADSTS7500525 con plugin SAML

Ciao!!

Avevamo il plugin SAML funzionante con il nostro AzureAD, ma ieri, dopo l’aggiornamento all’ultimo commit, abbiamo iniziato a vedere i seguenti errori quando gli utenti tentano di autenticarsi tramite SAML:

Accesso
Spiacenti, si è verificato un problema durante l'accesso.

AADSTS7500525: Si è verificato un errore XML nel messaggio SAML alla riga 1, posizione 1. Verificare che il contenuto XML dei messaggi SAML sia conforme alle specifiche del protocollo SAML.

Questo link Azure AD SAML2 request rejected: AADSTS7500525 - Microsoft Q&A suggerisce che ciò possa essere causato da “Richieste di autenticazione SAML compresse” che AzureAD non supporta.

I commit di dicembre contengono molte modifiche a SAML (configurazione tramite impostazioni del sito, ad esempio), ma non sono riuscito a capire se ci sono state modifiche relative alle richieste SAML che potrebbero aver causato questo problema.

Configurazione SAML (funzionante fino all’aggiornamento):

## Impostazione del plugin Saml
  DISCOURSE_SAML_TARGET_URL: https://login.microsoftonline.com/<<il nostro id app>>/saml2
  DISCOURSE_SAML_CERT_FINGERPRINT: "<<la nostra impronta digitale>>"
  DISCOURSE_SAML_REQUEST_METHOD: POST
  #DISCOURSE_SAML_FULL_SCREEN_LOGIN: true
  DISCOURSE_SAML_CERT: "-----BEGIN CERTIFICATE-----
<<Il nostro payload del certificato>>
-----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

Come posso abilitare il debug dell’autenticazione per ottenere maggiori informazioni a riguardo?

1 Mi Piace

Mi dispiace sentire che stai riscontrando problemi! Hai ragione, ho fatto molte rifattorizzazioni sul plugin SAML nelle ultime settimane, quindi potrebbe essere correlato.

Quando succede? Quando gli utenti avviano l’accesso? O quando vengono reindirizzati a Discourse?

C’è la possibilità che tu possa condividere qui l’URL del tuo sito, o tramite messaggio privato?

1 Mi Piace

Questo accade ogni volta che un utente deve accedere (una sessione è scaduta o un nuovo utente tenta di accedere).

Ha iniziato ad accadere dopo l’aggiornamento alla revisione 9334abe249 (prima era sulla 959923d3cf).

Mi dispiace ma il nostro forum è ospitato internamente in un account AWS privato, quindi non potrai accedervi dall’esterno della nostra rete.

Dove compare l’errore? Nei log di Discourse? Sullo schermo dell’utente? In Azure?

Potresti condividere alcuni screenshot?

1 Mi Piace

Ho anche provato a cercare qualcosa nei log di Discourse, ma poiché l’errore si verifica sul lato Azure, non ho trovato alcun messaggio di errore lì.

Nel file production.log il processo di login si ferma qui (probabilmente in attesa di un ritorno da 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.

Il team responsabile di Azure sta cercando di ottenere l’XML che stanno ricevendo, quindi forse potremo vedere qualcosa di “diverso” in esso. Ti farò sapere quando me lo invieranno.

1 Mi Piace

L’errore si verifica dopo che l’utente fa clic sul pulsante di accesso.
Quindi viene reindirizzato alla pagina di accesso di Azure con il seguente errore:

Temo che sia difficile capire cosa sta succedendo qui senza accedere al sito.

Il passo successivo sarebbe provare a ottenere l’XML che viene ricevuto da Azure e capire cosa c’è che non va. Dovresti essere in grado di farlo controllando il payload negli strumenti per sviluppatori del browser, e quindi decodificandolo usando uno strumento come questo

2 Mi Piace

Ottimo!

Il ritorno della richiesta è un codice 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

Il SAMLRequest gonfiato è (alcuni ID nascosti per 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>

Una cosa che ho notato confrontando la mia richiesta con l’esempio su Single sign-on SAML protocol - Microsoft identity platform | Microsoft Learn è che nella mia AuthnRequest non abbiamo il parametro

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

Sembra che il mio recente refactoring abbia inavvertitamente aggiunto la compressione per il binding POST SAML. Ho annullato tale modifica del comportamento in FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub

Puoi provare ad aggiornare il plugin SAML e vedere se le cose funzionano meglio?

4 Mi Piace

Ciao David,

Dopo l’aggiornamento a FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub l’autenticazione SAML è tornata alla normalità qui.

Grazie per l’aiuto e per tutto il lavoro sul plugin!

1 Mi Piace

Questo argomento è stato chiuso automaticamente dopo 20 ore. Non sono più consentite nuove risposte.