Certificado autofirmado para un SSO SAML iniciado por IdP

Question

Certificado autofirmado para un SSO SAML iniciado por IdP

#1 de a CVn (7 votos)

5

Actuamos como un proveedor de servicios en una integración SAML SSO con nuestros clientes. Durante las pruebas de desarrollo y etapas, generalmente intercambiamos archivos de metadatos y puntos finales de SSO.

Cuando formamos nuestros metadatos, usamos la herramienta de línea de comandos openssl para generar un certificado autofirmado que establece el valor del nodo X509Certificate en:

openssl genrsa -out server.pem 1024
openssl req -new -key server.pem -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.pem -out server.crt

Ahora, la pregunta es , cuando vaya a producción , deberíamos obtener un certificado legítimo de un tercero, o simplemente podemos regenerar un nuevo autofirmado ¿certificado? ¿Qué potencial de seguridad u otras implicaciones podríamos tener si usamos uno autofirmado?

Nota: nosotros, como proveedor de servicios, no enviamos mensajes SAML en este tipo de configuración iniciada por IdP.

Uso de Python, Django y paquete djangosaml2 (si es relevante).

certificates openssl sso saml

pregunta alecxe 22.12.2016 - 18:56

fuente

1 respuesta

Lea otras preguntas en las etiquetas certificates openssl sso saml

Diferencias en el mecanismo de seguridad entre las API de Google y Amazon ¿Hay algún bloqueador de pantalla de escritorio de OpenBSD seguro?

score 7 · Accepted Answer

TL; DR: Los certificados autofirmados están bien, e incluso se recomiendan al menos en algunos contextos. Use tiempos de validez prolongados para evitar problemas de transferencia de claves, y si usa RSA, use al menos claves de 2048 bits.

SAML 2.0 incluye el certificado que debe usarse para la validación de firmas y como destinatario de cifrado como parte de los metadatos de SAML (técnicamente, dentro de EntityDescriptor ).

Se supone que la entidad que utiliza los metadatos debe validar los metadatos de forma "conocida". Esto podría ser, por ejemplo, descargándolo solo a través de un canal de confianza (por ejemplo, a través de HTTPS con validación de certificado normal), o almacenando una copia de los metadatos localmente que se haya obtenido y verificado de alguna otra manera confiable.

En la práctica, los metadatos también suelen estar firmados con XML, lo que proporciona un nivel adicional de validación de integridad por encima y más allá de la protección que ofrece, por ejemplo, HTTPS. (Esto es algo bueno, en particular, dada la cantidad de implementaciones que parecen requerir la descarga y almacenamiento manual de los metadatos en lugares donde podrían modificarse fácilmente, de manera accidental o maliciosa. Al menos, la firma XML no puede validarse, lo que hace que los metadatos se rechacen más bien de metadatos potencialmente incorrectos que se utilizarán.)

Si no puede intercambiar metadatos SAML mientras se asegura la integridad de dichos metadatos, entonces tiene un problema de arranque significativo, al punto de que ni siquiera estoy seguro de que sea posible usar SAML en una manera segura Si no puede confiar en el certificado que forma parte de los metadatos, eso implica que no puede confiar en nada else en los metadatos tampoco , incluidos, por ejemplo, los URI de punto final.

Si puede intercambiar metadatos SAML mientras se asegura su integridad, entonces, por definición, contiene un blob de certificado de confianza, que está destinado (sujeto a las restricciones establecidas en los metadatos) para ser usado para:

Valide la firma en cualquier dato SAML entrante, incluidas las solicitudes de autenticación y las respuestas de autenticación, desde la entidad para la cual se generan los metadatos
Sirve como una clave de destinatario para datos SAML encriptados para la entidad para la cual se generan los metadatos (tenga en cuenta que todas las implementaciones no admiten XML encriptado con SAML)

Como ese certificado (de los metadatos de confianza) es, por definición, confiable, el uso de un certificado firmado por una entidad emisora de certificados no proporciona un beneficio significativo sobre el uso de un certificado autofirmado. Por lo tanto, no hay razón para usar un certificado firmado por una CA, y alguna razón para no (por ejemplo, en Internet2 se recomienda usar certificados con una validez de al menos 10 años; no conozco ninguna CA comercial) proporcionando certificados con esa validez larga).

Por mencionar, aunque hay un ejemplo bastante anecdótico, los Servicios de federación de Active Directory de Microsoft (ADFS) parecen estar perfectamente contentos con los certificados autofirmados en metadatos SAML; lo he hecho en el lado del SP bastante exactamente lo mismo que tiene, en las pruebas, con ADFS actuando como IdP.