SAML 2.0 — meccanismo e sicurezza

Voci di Glossario Sicurezza Informatica
Indice dei contenuti

    SAML 2.0 (Security Assertion Markup Language) è lo standard OASIS per la federazione delle identità e il Single Sign-On in ambienti enterprise. Usa asserzioni XML firmate digitalmente per comunicare informazioni sull’identità e gli attributi di un utente tra un Identity Provider e un Service Provider. Nonostante l’età (2005) è ancora il protocollo dominante per l’integrazione SSO tra organizzazioni diverse e per le applicazioni enterprise che preesistono all’era delle API REST.

    Anatomia di un’asserzione SAML

    Un’asserzione SAML è un documento XML strutturato in tre tipi di statement:

    Authentication statement: attesta che l’IdP ha verificato l’identità del subject (NameID) in un determinato momento con un certo metodo di autenticazione.

    Attribute statement: trasporta attributi dell’utente (email, ruolo, gruppi di appartenenza, dipartimento) che l’SP usa per l’autorizzazione.

    Authorization decision statement: (raro) attesta che il subject è autorizzato a compiere una specifica azione su una risorsa.

    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="_abc123" IssueInstant="2026-05-04T10:00:00Z"
  Version="2.0">
  <saml:Issuer>https://idp.esempio.it</saml:Issuer>
  <ds:Signature>...</ds:Signature>   <!-- firma XML dell'IdP -->
  <saml:Subject>
    <saml:NameID>mario.rossi@azienda.it</saml:NameID>
    <saml:SubjectConfirmation Method="...bearer">
      <saml:SubjectConfirmationData
        NotOnOrAfter="2026-05-04T10:05:00Z"
        Recipient="https://sp.app.com/acs"
        InResponseTo="_req456"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="..." NotOnOrAfter="..."
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.app.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>mario.rossi@azienda.it</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

    Flusso SP-initiated (più comune)

    1. L’utente accede a https://sp.app.com/risorsa-protetta
    2. L’SP genera una AuthnRequest con un ID univoco e la invia all’IdP (via redirect HTTP con la request codificata in Base64 nell’URL, o via HTTP POST)
    3. L’IdP autentica l’utente (login page, MFA)
    4. L’IdP genera un’asserzione SAML, la firma con la propria chiave privata, e la invia all’SP tramite HTTP POST al endpoint ACS (Assertion Consumer Service)
    5. L’SP verifica la firma con la chiave pubblica dell’IdP (scambiata nei metadati in fase di configurazione), valida le condizioni (NotBefore, NotOnOrAfter, Audience, InResponseTo) e stabilisce la sessione

    Sicurezza crittografica

    La fiducia si basa sulla firma digitale XML (XMLDSig): l’IdP firma l’asserzione (o l’intera Response) con la propria chiave privata RSA o ECDSA. L’SP verifica con la chiave pubblica corrispondente, ottenuta dai metadati dell’IdP al momento della configurazione della federazione.

    I metadati SAML sono il documento di configurazione che descrive IdP e SP: endpoint, certificati, binding supportati. Devono essere ottenuti tramite canale sicuro e verificati — metadati falsificati permettono attacchi MitM sul flusso SAML.

    Vulnerabilità principali

    XML Signature Wrapping (XSW): la vulnerabilità più critica di SAML. La firma XML copre un elemento specifico identificato da un ID. Un attaccante che può modificare la risposta prima che raggiunga l’SP può spostare l’elemento firmato in una posizione ignorata dall’SP e inserire un elemento non firmato (con contenuto arbitrario) nella posizione in cui l’SP lo cerca. L’SP verifica la firma — che è valida, perché l’elemento originale è ancora presente — ma usa i dati non firmati per l’autenticazione. Documentato in numerose implementazioni SAML. La contromisura è un parsing XML rigoroso che cerca esattamente l’elemento firmato tramite il suo ID, non per posizione nel documento.

    Golden SAML: se la chiave privata dell’IdP viene compromessa, l’attaccante può forgiare asserzioni SAML arbitrarie per qualsiasi utente verso qualsiasi SP configurato con quell’IdP. Vettore usato nell’attacco SolarWinds (2020) contro Microsoft 365: gli attaccanti hanno estratto le chiavi private di ADFS dai server on-premise compromessi.

    Replay attack: un’asserzione SAML intercettata può essere riusata se l’SP non mantiene un registro degli ID già usati (InResponseTo, AssertionID). L’SP deve rifiutare asserzioni con ID già visti e verificare che NotOnOrAfter non sia scaduto.

    Audience bypass: se l’SP non verifica che l’Audience dell’asserzione corrisponda al proprio entity ID, un’asserzione destinata a un altro SP può essere riusata — cross-tenant attack in ambienti multi-tenant.

    Ultimo aggiornamento: