How to deploy Rainbow SAML metadata into the Identity Provider

This article gives some recommendations on how to deploy Rainbow metadata for companies having activated SSO SAML authentication method,

Rainbow Metadata are used to automatically configure the Identity Provider (IDP) with Rainbow SAML URLs and certificates.

Even if it should rarely happen, it might be necessary to reload these metadata in the IDP in case of SAML certificate modification.

In such a scenario, companies who have not changed the default and are not implementing signature or encryption should update the data, although doing it with delay will not result in service disruption.

This certificate update would only be mandatory  for companies that have changed the default configuration and enabled  SAML request signatures, and/or encryption of SAML assertions. For those companies, the IdP administrator MUST update the Rainbow certificate information to avoid any service disruption.

Procedure:

SAML metadata is available for download in Rainbow admin menu Settings>Security:

We advise, whenever it is possible, to activate a regular polling of Rainbow metadata using the URL given into entityID section of SAML metadata. This would avoid any manual action in case of change.

https://openrainbow.com/api/rainbow/authentication/v1.0/saml/xxxx/metadata.xml

For IDP servers which do not propose the polling method based on an URL, the metadata must be uploaded manually. ALE would publish a notification if this was needed.

For Azure AD, it must be done manually:

For ADFS, in Relying Party Trust, "signature" tab:

The old certificate must be removed and replaced by the new one taken from metadata file.

Note: For current self signed certificate, it is necessary to add it into the trusted root authorities trust store.

Optional step:

Encryption of SAML assertion is not necessary as exchanges are already encrypted in HTTPS.

Nevertheless if encryption was enabled on the IDP, it is necessary to remove the old certificate and to add the new one into "Encryption" tab:

Rational about the use of a self signed certificate:

To reduce the operational complexity for managing SAML certificates renewal, and to comply with widest variety of SAML servers and of state of art operations, Rainbow now uses a self-signed certificate of long duration. This as a way to enable a long term solution without impairing security as ALE guarantees proper handling of this certificate management.

Why we use self-signed certificates for SAML feature in Rainbow ?

By using SAML 2.0, Rainbow has implemented a specific URL able to communicate the metadata related to a company. It includes the certificate that should be used for signature validation and as an encryption recipient.

The company that uses the metadata to configure their IDP in their specific way, can retrieve it from Rainbow either through API call or with a Web Client. Both cases use an HTTPS channel with normal certificate validation. It is called a secure communication channel.

By using this way, metadata retrieved for a company inside Rainbow can be considered as trusted metadata. Being trusted metadata, certificate blob contained inside it is considered as trusted.

As that certificate (from the trusted metadata) is by definition trusted, using a CA-signed certificate provides no significant benefit over using a self-signed certificate. There is thus no reason to use a CA-signed certificate, and some reason not to. For example, it can be recommended to use certificates with at least 10 years validity in some cases to avoid frequent renewal in your environment that could lead to manual or security errors.