Cet article donne quelques recommandations sur la manière de déployer les métadonnées Rainbow pour les entreprises ayant activé la méthode d'authentification SAML SSO,
Les métadonnées Rainbow sont utilisées pour configurer automatiquement le fournisseur d'identité (IDP) avec les URL et les certificats SAML Rainbow.
Même si cela ne se produit que rarement, il peut être nécessaire de recharger ces métadonnées dans l'IDP en cas de modification du certificat SAML.
Dans un tel scénario, les entreprises qui n'ont pas modifié les paramètres par défaut et qui ne mettent pas en œuvre de signature ou de cryptage devraient mettre à jour les données, même si le fait de le faire avec retard n'entraînera pas d'interruption de service.
Cette mise à jour du certificat ne serait obligatoire que pour les entreprises qui ont modifié la configuration par défaut et activé les signatures des demandes SAML et/ou le cryptage des assertions SAML. Pour ces entreprises, l'administrateur de l'IdP DOIT mettre à jour les informations du certificat Rainbow afin d'éviter toute interruption de service.
Procédure :
Les métadonnées SAML peuvent être téléchargées dans le menu d'administration Rainbow Settings>Security :
Nous vous conseillons, dans la mesure du possible, d'activer un sondage régulier des métadonnées Rainbow en utilisant l'URL indiquée dans la section entityID des métadonnées SAML. Cela évitera toute action manuelle en cas de changement.
https://openrainbow.com/api/rainbow/authentication/v1.0/saml/xxxx/metadata.xml
Pour les serveurs IDP qui ne proposent pas la méthode de sondage basée sur une URL, les métadonnées doivent être téléchargées manuellement. L'ALE publierait une notification si cela s'avérait nécessaire.
Pour Azure AD, cela doit être fait manuellement :
Pour ADFS, dans Relying Party Trust, onglet "signature" :
L'ancien certificat doit être supprimé et remplacé par le nouveau pris dans le fichier de métadonnées.
Note : Pour le certificat auto-signé actuel, il est nécessaire de l'ajouter dans le magasin de confiance des autorités racine.
Étape facultative :
Le chiffrement de l'assertion SAML n'est pas nécessaire car les échanges sont déjà chiffrés en HTTPS.
Néanmoins, si le chiffrement a été activé sur l'IDP, il est nécessaire de supprimer l'ancien certificat et d'ajouter le nouveau dans l'onglet "Chiffrement" :
Raison d'être de l'utilisation d'un certificat auto-signé :
Pour réduire la complexité opérationnelle de la gestion du renouvellement des certificats SAML, et pour se conformer à la plus grande variété de serveurs SAML et d'opérations de pointe, Rainbow utilise maintenant un certificat auto-signé de longue durée. C'est un moyen d'offrir une solution à long terme sans compromettre la sécurité, car l'ALE garantit une gestion correcte de ce certificat.
Pourquoi utiliser des certificats auto-signés pour la fonction SAML dans Rainbow ?
En utilisant SAML 2.0, Rainbow a mis en place une URL spécifique capable de communiquer les métadonnées relatives à une entreprise. Ces métadonnées comprennent le certificat qui doit être utilisé pour la validation de la signature et comme destinataire du cryptage.
L'entreprise qui utilise les métadonnées pour configurer son IDP de manière spécifique peut les reprendre auprès de Rainbow soit par un appel API, soit par un client web. Dans les deux cas, on utilise une chaîne d'information HTTPS avec une validation normale des certificats. C'est ce qu'on appelle un canal de communication sécurisé.
De cette manière, les métadonnées reprises pour une entreprise à l'intérieur de Rainbow peuvent être considérées comme des métadonnées de confiance. En tant que métadonnées de confiance, le blob de certificat qu'elles contiennent est considéré comme fiable.
Comme ce certificat (provenant des métadonnées de confiance) est par définition fiable, l'utilisation d'un certificat signé par une autorité de certification n'offre aucun avantage significatif par rapport à un certificat auto-signé. Il n'y a donc aucune raison d'utiliser un certificat signé par une autorité de certification, et certaines raisons de ne pas le faire. Par exemple, il peut être recommandé d'utiliser des certificats ayant une validité d'au moins 10 ans dans certains cas afin d'éviter des renouvellements fréquents dans votre environnement qui pourraient entraîner des erreurs manuelles ou de sécurité.