SAML

SAML (Security Assertion Markup Language) è uno standard di single sign-on (SSO) basato su XML pubblicato da OASIS nel 2005. Ampiamente utilizzato nelle integrazioni B2B enterprise — Okta, Ping Identity, Microsoft AD FS, Google Workspace, ogni SaaS che vende alle grandi aziende.

Il modello: un Identity Provider (IdP, ad es. Okta) autentica l’utente. L’utente arriva a un Service Provider (SP, ad es. Salesforce) con un’asserzione SAML firmata che prova chi è. L’SP verifica la firma rispetto alla chiave pubblica dell’IdP e si fida dell’affermazione.

SAML vs OAuth2/OIDC: SAML è più vecchio, basato su XML, progettato per l’SSO aziendale. OAuth/OIDC sono basati su JSON, progettati originariamente per l’autorizzazione delegata (“consenti a questa app di leggere la mia Gmail”) e successivamente estesi all’autenticazione (OIDC). Le nuove integrazioni enterprise usano sempre più OIDC; il SaaS enterprise esistente spesso richiede ancora SAML perché gli IdP dei clienti lo richiedono.

La specifica della firma XML utilizzata da SAML è notoriamente piena di insidie — gli attacchi di XML signature wrapping esistono su molte implementazioni. Le librerie moderne (es. python-saml, quelle di OneLogin) gestiscono questo correttamente per impostazione predefinita; fare da soli è una cattiva idea.

I binding SAML — come viaggia l’asserzione: SAML definisce diversi binding di trasporto. HTTP Redirect comprime e codifica in base64 la richiesta in una stringa di query URL (limitata dalla lunghezza URL del browser); HTTP POST invia un blob codificato in base64 in un form auto-inviato tramite JavaScript (il più comune nel 2026); HTTP Artifact passa un breve token di riferimento che l’SP scambia fuori banda per l’asserzione completa. POST è il default moderno perché gestisce dimensioni di asserzione che superano agevolmente i limiti URL e evita di far trapelare l’asserzione nei log proxy. L’asserzione stessa è racchiusa in base64 e firmata con SHA-256.

Insidie operative nei rollout SAML enterprise: sfasamento dell’orologio tra IdP e SP (le asserzioni hanno una finestra di validità di 5 minuti per impostazione predefinita — un orario server mal configurato interrompe l’accesso per tutti), rotazione del certificato (il certificato di firma dell’IdP scade ogni 1-3 anni e deve essere ruotato prima di quella data o tutto l’SSO fallisce simultaneamente) e mismatch del formato NameID (l’IdP emette emailAddress ma l’SP si aspetta ID opachi persistent). La classica guerra aziendale è un’interruzione SSO il lunedì mattina perché il certificato IdP è scaduto silenziosamente domenica sera e nessuno aveva in carico il rinnovo. Riferimento: Specifica OASIS SAML 2.0 Core.

Esempio pratico

Un dipendente clicca su “Accedi con SSO aziendale” su app.example.com. L’SP (Service Provider) genera un documento XML SAML <AuthnRequest> e lo invia in POST all’IdP su sso.acme.com/saml. L’IdP autentica l’utente (probabilmente tramite password + WebAuthn) e restituisce una <Response> SAML contenente un <Assertion> con: l’email dell’utente (NameID), le appartenenze ai gruppi (AttributeStatement), la finestra di validità (NotBefore / NotOnOrAfter ~5 minuti) e la restrizione del pubblico (deve essere esattamente app.example.com). L’XML è firmato con la chiave RSA-2048 dell’IdP usando SHA-256. Il browser invia automaticamente questo blob codificato in base64 di nuovo a app.example.com/saml/acs. L’SP verifica la firma rispetto al certificato pubblico pre-condiviso dell’IdP, controlla la finestra di validità e il pubblico, estrae l’email e crea una sessione locale. L’intero scambio consiste in due reindirizzamenti HTTP ed è invisibile all’utente oltre alla schermata di login dell’IdP.

Quando e perché è importante

Se vendi SaaS B2B, il supporto SAML è la funzionalità fondamentale per le vendite enterprise — la maggior parte delle aziende sopra i 500 dipendenti richiede che tutti gli accessi SaaS passino attraverso il proprio IdP per il controllo dell’offboarding (quando un dipendente se ne va, l’IdP revoca la sessione e perde l’accesso a ogni SaaS connesso contemporaneamente). I moderni incidenti di sicurezza presso i fornitori SaaS (Okta 2022, Cloudflare 2023) risalgono al livello SAML o del token di sessione piuttosto che specificamente alle password, perché l’SSO è la credenziale di riferimento. La checklist difensiva per qualsiasi implementazione SAML: validare la firma su ogni asserzione (non solo sul wrapper della risposta), validare InResponseTo per prevenire i replay, validare il pubblico e il destinatario, applicare rigorosamente la finestra temporale e memorizzare l’impronta digitale del certificato IdP fuori banda in modo che un URL di metadati compromesso non possa silenziosamente scambiare la chiave attendibile. Riferimento: OWASP SAML Security Cheat Sheet.