Questo articolo fornisce alcuni consigli su come distribuire i metadati Rainbow per le aziende che hanno attivato il metodo di autenticazione SSO SAML,
I metadati Rainbow sono utilizzati per configurare automaticamente l'Identity Provider (IDP) con gli URL e i certificati SAML Rainbow.
Anche se ciò accade raramente, potrebbe essere necessario ricaricare questi metadati nell'IDP in caso di modifica del certificato SAML.
In questo scenario, le aziende che non hanno modificato il default e non stanno implementando la firma o la crittografia dovrebbero aggiornare i dati, anche se farlo con ritardo non comporterà un'interruzione del servizio.
L'aggiornamento del certificato sarebbe obbligatorio solo per le aziende che hanno modificato la configurazione predefinita e abilitato le firme delle richieste SAML e/o la crittografia delle asserzioni SAML. Per queste aziende, l'amministratore dell'IdP DEVE aggiornare le informazioni del certificato Rainbow per evitare qualsiasi interruzione del servizio.
Procedura:
I metadati SAML sono disponibili per il download nel menu' di amministrazione di Rainbow, Impostazioni>Sicurezza:
Consigliamo, quando è possibile, di attivare un sondaggio regolare dei metadati Rainbow utilizzando l'URL indicato nella sezione entityID dei metadati SAML. Questo eviterebbe qualsiasi azione manuale in caso di modifica.
https://openrainbow.com/api/rainbow/authentication/v1.0/saml/xxxx/metadata.xml
Per i server IDP che non propongono il metodo di sondaggio basato su un URL, i metadati devono essere caricati manualmente. ALE pubblicherebbe una notifica se fosse necessario.
Per Azure AD, deve essere fatto manualmente:
Per ADFS, in Relying Party Trust, scheda "firma":
Il vecchio certificato deve essere rimosso e sostituito da quello nuovo preso dal file di metadati.
Nota: per il certificato attuale autofirmato, è necessario aggiungerlo all'archivio di fiducia delle autorità radice.
Passo facoltativo:
La crittografia dell'asserzione SAML non è necessaria, poiché gli scambi sono già crittografati in HTTPS.
Tuttavia, se la crittografia è stata attivata sull'IDP, è necessario rimuovere il vecchio certificato e aggiungere il nuovo nella scheda "Crittografia":
Razionale sull'uso di un certificato autofirmato:
Per ridurre la complessità operativa della gestione del rinnovo dei certificati SAML e per conformarsi alla più ampia varietà di server SAML e di operazioni allo stato dell'arte, Rainbow utilizza ora un certificato autofirmato di lunga durata. Questo è un modo per consentire una soluzione a lungo termine senza compromettere la sicurezza, in quanto ALE garantisce la corretta gestione di questo certificato.
Perché utilizziamo i certificati autofirmati per la funzione SAML in Rainbow?
Utilizzando SAML 2.0, Rainbow ha implementato un URL specifico in grado di comunicare i metadati relativi a un'azienda. Include il certificato da utilizzare per la convalida della firma e come destinatario della crittografia.
L'azienda che utilizza i metadati per configurare il proprio IDP in modo specifico, può recuperarli da Rainbow attraverso una chiamata API o con un client web. Entrambi i casi utilizzano un canale HTTPS con la normale convalida del certificato. Si chiama canale di comunicazione sicuro.
Utilizzando questo modo, i metadati recuperati per un'azienda all'interno di Rainbow possono essere considerati come metadati attendibili. Essendo metadati attendibili, il blob del certificato contenuto al suo interno è considerato attendibile.
Poiché quel certificato (dai metadati attendibili) è per definizione attendibile, l'utilizzo di un certificato firmato da una CA non offre alcun vantaggio significativo rispetto all'utilizzo di un certificato autofirmato. Non c'è quindi alcun motivo per utilizzare un certificato firmato da una CA, e alcuni motivi per non farlo. Ad esempio, in alcuni casi si può consigliare di utilizzare certificati con validità di almeno 10 anni, per evitare che il rinnovo frequente nel suo ambiente possa portare a errori manuali o di sicurezza.