SAML e federazione

SAML (Security Assertion Markup Language) è uno standard basato su XML per lo scambio di dati di autenticazione e autorizzazione, predominante nell'SSO aziendale.

• Consente a un identity provider aziendale di attestare l'identità di un utente a molte applicazioni.
• SAML 2.0 è precedente a OIDC e rimane profondamente radicato nell'identità B2B e aziendale.

Comprendere SAML è essenziale per difendere la federazione aziendale, in cui un'unica falla nel rapporto di fiducia espone ogni app collegata.

La federazione SAML ha due parti principali.

• L'Identity Provider (IdP) autentica l'utente ed emette asserzioni (Okta, Entra ID, Ping).
• Il Service Provider (SP) è l'applicazione che si fida dell'IdP e concede l'accesso.

Il rapporto di fiducia viene stabilito fuori banda scambiando metadati, inclusi certificati di firma e URL degli endpoint.

L'artefatto centrale è l'assertion, un documento XML che dichiara che l'IdP ha autenticato un soggetto.

• Subject identifica l'utente (NameID).
• Conditions definisce la finestra di validità e l'audience prevista.
• AuthnStatement registra come e quando è avvenuta l'autenticazione.
• AttributeStatement contiene ruoli, email e claim relativi ai gruppi.

Il modello più comune è l'SSO SP-initiated.

• L'utente accede allo SP, che genera una AuthnRequest e reindirizza l'utente all'IdP.
• L'IdP autentica l'utente e invia tramite POST una Response firmata all'Assertion Consumer Service (ACS) dello SP.
• Lo SP convalida l'asserzione e crea una sessione locale.

La sicurezza SAML si basa sulle firme digitali XML. L'IdP firma l'asserzione e/o la risposta con la propria chiave privata; lo SP verifica la firma usando il certificato attendibile.

• Firmare l'asserzione stessa, non soltanto la risposta esterna.
• Verificare la firma usando un certificato IdP vincolato nei metadati, non uno incorporato nel messaggio.

La maggior parte degli attacchi SAML prende di mira la logica di convalida delle firme.

XML Signature Wrapping è la classe di attacchi alle firme specifica di SAML. L'attaccante mantiene un elemento validamente firmato, ma aggiunge una seconda asserzione contraffatta che la logica applicativa legge effettivamente.

• La firma continua a essere verificata rispetto al frammento originale.
• La logica di business elabora però l'asserzione iniettata e non firmata.

Mitigazione: usare una libreria SAML robusta, verificare che l'elemento firmato sia quello effettivamente utilizzato e rifiutare i documenti con asserzioni multiple o ambigue.

Un'asserzione deve essere vincolata allo SP previsto. SAML fornisce restrizioni esplicite.

• AudienceRestriction indica l'entity ID dello SP per cui l'asserzione è valida.
• Recipient in SubjectConfirmation deve corrispondere all'URL ACS.

Lo SP deve applicare queste restrizioni. Saltare il controllo dell'audience consente di riutilizzare in un'altra app un'asserzione emessa per una sola applicazione.

Le asserzioni sono credenziali di breve durata e monouso. Gli SP devono farlo rispettare.

• Rispettare NotBefore e NotOnOrAfter con una tolleranza ridotta per la deriva dell'orologio.
• Tracciare l'ID dell'asserzione e rifiutare qualsiasi riutilizzo durante la finestra di validità.
• Richiedere TLS sull'endpoint ACS.

Senza il rilevamento dei replay, un'asserzione intercettata può essere inviata nuovamente prima della sua scadenza.

La federazione estende l'SSO oltre i confini organizzativi, talvolta tramite hub o broker che traducono tra protocolli.

• Ogni collegamento di trust è un potenziale punto debole; un IdP compromesso può impersonare ogni utente.
• I broker di identità possono fare da ponte tra SAML e OIDC, richiedendo un'attenta mappatura dei claim.

Applichi il principio del privilegio minimo alla mappatura degli attributi e monitori la comparsa imprevista di nuove registrazioni di SP.

Modalità di errore ricorrenti in SAML da verificare:

• La firma non viene verificata, oppure è firmata la risposta ma non l'asserzione.
• Vulnerabilità a XML Signature Wrapping.
• Assenza di controlli di audience/destinatario.
• Assenza di protezione dal replay o finestre di validità eccessivamente lunghe.
• Analisi di XML External Entity (XXE) sull'SP.
• Fiducia nel certificato incorporato nel messaggio invece che nei metadati configurati tramite certificate pinning.

Entrambi forniscono SSO, ma differiscono nella progettazione.

• SAML basato su XML, binding POST/redirect del browser, molto diffuso in ambito enterprise e workforce, con strumenti maturi.
• OIDC basato su JSON/JWT, compatibile con REST, più adatto al mobile e alle SPA.

Molte organizzazioni utilizzano entrambi. Chi si occupa della difesa deve conoscere le regole di convalida delle asserzioni per il protocollo usato da ciascuna applicazione, poiché la superficie d'attacco è diversa.

Selezioni la difesa migliore per l'attacco descritto.

Punti chiave:

• SAML è un SSO aziendale basato su XML tra un IdP e un SP che utilizza asserzioni firmate.
• La sicurezza dipende dalla corretta convalida della firma XML rispetto a un certificato sottoposto a pinning.
• Difenda i sistemi da XML Signature Wrapping, replay e XXE.
• Applichi sempre le restrizioni di audience/destinatario e le finestre di validità.
• La federazione amplia la fiducia, ma moltiplica il raggio d'impatto di un IdP compromesso.