Decodificatore SAML

Lo strumento supporta Response SAML e Asserzione XML codificate in Base64, comunemente presenti nei reindirizzamenti SAML e nei binding POST. Rileva inoltre automaticamente e decomprime le richieste SAML con compressione deflate.

Sì. Tutta l'elaborazione avviene interamente nel tuo browser. I tuoi token SAML non vengono mai inviati ad alcun server. Nessun dato lascia il tuo dispositivo.

Le richieste SAML inviate tramite reindirizzamento HTTP sono spesso compresse con deflate prima della codifica Base64 per ridurre la lunghezza dell'URL. Questo strumento rileva e decomprime automaticamente tali dati.

Una richiesta è una samlp:AuthnRequest che il service provider invia per chiedere all'identity provider di autenticare un utente; una risposta è la samlp:Response che torna indietro, contenente la saml:Assertion con l'istruzione di autenticazione e gli attributi. Entrambe viaggiano codificate in URL (binding Redirect) o dentro un form HTML in POST (binding POST). Questo strumento decodifica entrambe le direzioni.

È una stringa opaca che l'SP allega alla richiesta e che l'IdP deve restituire invariata con la risposta - in genere l'URL a cui reindirizzare dopo il login. La specifica dei binding SAML raccomanda di tenerla sotto gli 80 byte e per l'IdP non ha alcun significato. Quando l'SSO atterra sulla pagina sbagliata, un RelayState perso o corrotto è il primo sospetto.

Nel binding HTTP-Redirect l'XML viene compresso con raw-Deflate, poi codificato in Base64 e infine in URL - i tre passaggi previsti dalla specifica. Dai a questo strumento il valore codificato in URL: se si espande in markup che inizia con <, era compresso; se inizia già con <?xml o <saml, non lo era. I messaggi del binding POST sono in Base64 senza Deflate.

Lo sfasamento degli orologi - la validazione della firma fallisce quando gli orologi di SP e IdP differiscono più della tolleranza consentita; la mancata corrispondenza dell'audience - la audienceRestriction nell'asserzione non contiene l'entity ID dell'SP; e le risposte scadute (NotOnOrAfter). Cause comuni sono anche un RelayState mancante e asserzioni non firmate dove l'SP le richiede. I campi decodificati mostrati da questo strumento ti permettono di verificare direttamente ciascuno di questi punti.

Sì - decodificare non significa verificare. L'XML dell'asserzione è leggibile da chiunque; la firma al suo interno tutela l'integrità, non la riservatezza. Ciò che non puoi fare senza il certificato pubblico dell'IdP è dimostrare che l'asserzione è autentica e non modificata. Tratta con cautela qualsiasi contenuto decodificato: le asserzioni spesso contengono indirizzi email, gruppi e entitlements.