¿Es seguro permitir HTTP para la URL del emisor de SAML 2.0?

De hecho, es seguro usar HTTP para la URL del Emisor. No hay intercambio de información confidencial entre un proveedor de servicios y un proveedor de identidad en la URL del Emisor, por lo que el protocolo para ese valor puede ser ambiguo. Las otras URL que representan la URL del proveedor de identidad deben estar absolutamente en HTTPS, de lo contrario estaría exponiendo su servicio a proveedores de identidad que son vulnerables a los ataques MITM.

La URL del Emisor simplemente sirve un archivo XML con metadatos sobre su implementación SAML. No es raro ver las URL de HTTPS para la URL del Emisor, ya que normalmente se encuentra en el mismo dominio que el proveedor de identidad. Este no es siempre el caso, sin embargo. Okta y ADFS son dos servicios que alojan el metadato XML en un dominio separado, que puede no tener HTTPS.

Creo que técnicamente, HTTP para la URL del emisor está bien ya que los datos que se están La transmisión es menos sensible. Sin embargo, también diría que hacerlo HTTPS tambien esta bien En el pasado, existía la creencia de que solo debería usar HTTPS donde era absolutamente necesario debido a los gastos generales adicionales involucrados y El rendimiento potencial golpea. Con el aumento de velocidades y potencia de procesamiento, este argumento ya no es tan válido (aunque todavía hay muchos sitios con una arquitectura que se basa en gran medida en el almacenamiento en caché para el rendimiento donde HTTPS puede tener un impacto global adverso).

Tiendo a sentir que la complejidad es ahora una de nuestras principales amenazas. Tener un La aplicación que usa HTTP en algunos contextos y HTTPS en otros agrega a esto Complejidad y dificulta la verificación. Mucho más fácil de monitorear y modificar todo está bien si todo lo que necesita hacer es asegurarse de que todas las conexiones estén HTTPS en lugar de tener que verificar todas las conexiones que no son HTTPS están bien.