Parser SAML

SAML (Security Assertion Markup Language) e uno standard basato su XML per lo scambio di dati di autenticazione e autorizzazione tra provider di identita (IdP) e provider di servizi (SP). Questo strumento decodifica i messaggi SAML dagli URL, gestisce la codifica Base64 e la compressione DEFLATE, e formatta l'XML per l'ispezione.

Specifiche

• OASIS SAML 2.0 Core
• OASIS SAML 2.0 Bindings
• SAML 2.0 Technical Overview

Casi d'uso comuni

• Debug dei flussi di autenticazione Enterprise Single Sign-On (SSO)
• Ispezione delle asserzioni SAML dai provider di identita (Okta, Azure AD, ADFS)
• Risoluzione dei problemi di integrazione SAML tra servizi
• Verifica degli attributi dell'asserzione e dei valori NameID
• Analisi di AuthnContext e parametri di sessione
• Audit delle configurazioni SAML per la revisione di sicurezza

Funzionalità

• Analisi dei messaggi SAML AuthnRequest (SP verso IdP)
• Decodifica di SAML Response e Assertion (IdP verso SP)
• Estrazione di SAMLRequest e SAMLResponse dai parametri di query URL
• Gestione della codifica Base64 e compressione DEFLATE (binding HTTP-Redirect)
• Formattazione della struttura XML con evidenziazione della sintassi
• Visualizzazione della panoramica del messaggio (tipo, ID, IssueInstant, Destination, Status)
• Estrazione di Issuer, Subject/NameID e Conditions
• Visualizzazione degli attributi dell'asserzione dall'AttributeStatement
• Indicatore di presenza della firma

Esempi

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlLz4=

Suggerimenti

• SAML utilizza due binding principali: HTTP-Redirect (GET con deflate+base64) e HTTP-POST (POST con base64).
• Il parametro RelayState preserva l'URL originariamente richiesto durante il flusso SSO.
• Le asserzioni SAML possono essere firmate, crittografate o entrambe le cose. Questo strumento mostra il contenuto decodificato.
• Controlla le condizioni NotBefore e NotOnOrAfter per validare la tempistica dell'asserzione.

Approfondimenti Parser SAML

SAML (Security Assertion Markup Language) e uno standard aperto basato su XML per lo scambio di dati di autenticazione e autorizzazione tra un Identity Provider (IdP) e un Service Provider (SP). SAML 2.0, pubblicato da OASIS nel 2005, rimane il protocollo dominante per l'Enterprise Single Sign-On (SSO), consentendo ai dipendenti di autenticarsi una volta e accedere a piu applicazioni.

Un flusso SAML SSO funziona nel seguente modo: un utente tenta di accedere a un service provider, l'SP genera un AuthnRequest e reindirizza il browser verso l'IdP, l'IdP autentica l'utente e crea una SAML Response contenente Assertion, e il browser invia questa Response via POST all'SP. L'asserzione contiene l'identita dell'utente (NameID), gli attributi (email, gruppi, ruoli) e le condizioni (finestra di validita, restrizione del pubblico).

I messaggi SAML vengono trasportati tramite binding. Il binding HTTP-Redirect codifica l'XML usando compressione DEFLATE e codifica Base64 in un parametro di query URL. Il binding HTTP-POST usa solo Base64 e invia tramite un modulo ad invio automatico. Il debug di SAML richiede la decodifica di questi livelli per ispezionare l'XML sottostante.

Le asserzioni SAML possono essere firmate (per dimostrare che provengono dall'IdP), crittografate (per impedire agli intermediari di leggere il contenuto) o entrambe le cose. Quando si risolvono problemi di SSO, il primo passo e sempre decodificare la SAML Response e verificare le condizioni, il pubblico, i timestamp e i valori degli attributi dell'asserzione.

SAML e OAuth 2.0/OpenID Connect servono scopi diversi. SAML e progettato per l'SSO enterprise utilizzando asserzioni basate su XML trasportate tramite reindirizzamenti del browser, ed e piu comune negli ambienti enterprise con provider di identita come ADFS e Okta. OAuth 2.0 e un framework di autorizzazione per l'accesso alle API utilizzando token JSON, e OpenID Connect aggiunge un livello di autenticazione sopra OAuth utilizzando JWT. OIDC e piu comune nelle applicazioni web e mobile moderne, mentre SAML rimane dominante negli ambienti IT aziendali.

I messaggi SAML appaiono spesso come stringhe incomprensibili perche sono codificati per il trasporto. Nel binding HTTP-POST, l'XML e codificato in Base64. Nel binding HTTP-Redirect, l'XML viene prima compresso con DEFLATE, poi codificato in Base64, poi codificato come URL. Leggere l'XML originale richiede l'inversione di questi livelli nell'ordine corretto. Questo strumento gestisce automaticamente tutti i passaggi di decodifica indipendentemente dal binding utilizzato.

Quando si risolvono errori SAML, verificare diverse cause comuni: lo sfasamento dell'orologio tra IdP e SP puo far fallire la validazione dei timestamp dell'asserzione; l'elemento Audience deve corrispondere esattamente all'Entity ID configurato dell'SP; le asserzioni potrebbero aver superato il tempo NotOnOrAfter; l'attributo Destination deve corrispondere all'URL dell'Assertion Consumer Service (ACS) dell'SP; e l'SP potrebbe non avere il certificato di firma attuale dell'IdP se e stato recentemente ruotato. Il parametro RelayState svolge anche un ruolo importante nel flusso SSO — preserva l'URL originariamente richiesto dall'utente attraverso il reindirizzamento di autenticazione, in modo che dopo l'autenticazione riuscita, l'SP possa reindirizzare alla pagina che l'utente aveva inizialmente tentato di accedere.