È sicuro consentire HTTP per l'URL dell'emittente SAML 2.0?

È infatti sicuro utilizzare HTTP per l'URL dell'emittente. Non c'è scambio di informazioni sensibili tra un fornitore di servizi e un provider di identità sull'URL dell'emittente, pertanto il protocollo per tale valore può essere ambiguo. Gli altri URL che rappresentano l'URL del provider di identità dovrebbero assolutamente essere su HTTPS, altrimenti esporresti il tuo servizio ai provider di identità che sono vulnerabili agli attacchi MITM.

L'URL dell'emittente serve solo un file XML con metadati relativi all'implementazione SAML. Non è raro vedere gli URL HTTPS per l'URL dell'emittente, poiché generalmente è ospitato nello stesso dominio del provider di identità. Questo non è sempre il caso però. Okta e ADFS sono due servizi che ospitano l'XML dei metadati su un dominio separato, che potrebbe non avere HTTPS.

Credo che tecnicamente, HTTP per l'URL dell'emittente sia OK dato che i dati sono trasmesso è meno sensibile. Tuttavia, vorrei anche sostenere che rendendolo HTTPS va bene anche In passato, c'era la convinzione che dovresti usare solo HTTPS dove è assolutamente necessario a causa delle spese generali aggiuntive coinvolte e potenziali risultati delle prestazioni. Con l'aumento delle velocità e della potenza di elaborazione, questo argomento non è più valido (sebbene ci siano ancora molti siti con un architettura che fa molto affidamento sulla memorizzazione nella cache per le prestazioni in cui è possibile utilizzare HTTPS avere un impatto complessivo negativo).

Tendo a sentire che la complessità è ora una delle nostre principali minacce. Avere un l'applicazione che usa HTTP in alcuni contesti e HTTPS in altri aggiunge a questo complessità e rende la verifica più difficile. Molto più facile da monitorare e chiarire tutto va bene se tutto ciò che devi fare è assicurarti che tutte le connessioni siano HTTPS anziché dover controllare tutte le connessioni non HTTPS sono OK.