Este artículo ofrece algunas recomendaciones sobre cómo desplegar los metadatos Rainbow para empresas que tengan activado el método de autenticación SAML SSO,
Los metadatos Rainbow se utilizan para configurar automáticamente el proveedor de identidades (IDP) con las URL y los certificados SAML de Rainbow.
Aunque rara vez ocurra, podría ser necesario recargar estos metadatos en el IDP en caso de modificación del certificado SAML.
En tal caso, las empresas que no hayan modificado el predeterminado y no estén implementando la firma o el cifrado deberán actualizar los datos, aunque hacerlo con retraso no supondrá una interrupción del servicio.
Esta actualización del certificado sólo sería obligatoria para las empresas que hayan cambiado la configuración por defecto y hayan habilitado las firmas de las solicitudes SAML, y/o el cifrado de las aserciones SAML. Para esas empresas, el administrador del IdP DEBE actualizar la información del certificado Rainbow para evitar cualquier interrupción del servicio.
Procedimiento:
Los metadatos SAML están disponibles para su descarga en el menú de administración de Rainbow Configuración>Seguridad:
Aconsejamos, siempre que sea posible, activar un sondeo regular de los metadatos Rainbow utilizando la URL que figura en la sección entityID de los metadatos SAML. Esto evitaría cualquier acción manual en caso de cambio.
https://openrainbow.com/api/rainbow/authentication/v1.0/saml/xxxx/metadata.xml
Para los servidores IDP que no propongan el método de sondeo basado en una URL, los metadatos deberán cargarse manualmente. ALE publicaría una notificación si esto fuera necesario.
Para Azure AD, debe hacerse manualmente:
Para ADFS, en Confianza de la parte de confianza, pestaña "firma":
El certificado antiguo debe ser eliminado y sustituido por el nuevo tomado del archivo de metadatos.
Nota: Para el certificado autofirmado actual, es necesario añadirlo al almacén de confianza de las autoridades raíz de confianza.
Paso opcional:
La encriptación de la aserción SAML no es necesaria puesto que los intercambios ya están encriptados en HTTPS.
No obstante, si el cifrado estaba activado en el IDP, es necesario eliminar el certificado antiguo y añadir el nuevo en la pestaña "Cifrado":
Racional sobre el uso de un certificado autofirmado:
Para reducir la complejidad operativa de la gestión de la renovación de los certificados SAML, y para cumplir con la mayor variedad de servidores SAML y de operaciones de última generación, Rainbow utiliza ahora un certificado autofirmado de larga duración. Esto como una forma de permitir una solución a largo plazo sin perjudicar la seguridad, ya que ALE garantiza el manejo adecuado de esta gestión de certificados.
¿Por qué utilizamos certificados autofirmados para la función SAML en Rainbow?
Al utilizar SAML 2.0, Rainbow ha implementado una URL específica capaz de comunicar los metadatos relacionados con una empresa. Incluye el certificado que debe utilizarse para la validación de la firma y como destinatario del cifrado.
La empresa que utiliza los metadatos para configurar su IDP a su manera específica, puede recuperarlos de Rainbow mediante una llamada API o con un cliente web. En ambos casos se utiliza un canal HTTPS con validación de certificado normal. Es lo que se denomina un canal de comunicación seguro.
De este modo, los metadatos recuperados para una empresa dentro de Rainbow pueden considerarse metadatos de confianza. Al ser metadatos de confianza, el blob de certificado que contiene se considera de confianza.
Como ese certificado (de los metadatos de confianza) es de confianza por definición, utilizar un certificado firmado por una CA no aporta ninguna ventaja significativa sobre el uso de un certificado autofirmado. Por tanto, no hay razón para utilizar un certificado firmado por una CA, y sí para no hacerlo. Por ejemplo, en algunos casos puede ser recomendable utilizar certificados con al menos 10 años de validez para evitar renovaciones frecuentes en su entorno que podrían dar lugar a errores manuales o de seguridad.