Dieser Artikel enthält einige Empfehlungen zur Bereitstellung von Rainbow-Metadaten für Unternehmen, die die SSO SAML-Authentifizierungsmethode aktiviert haben,
Rainbow-Metadaten werden verwendet, um den Identity Provider (IDP) automatisch mit Rainbow SAML URLs und Zertifikaten zu konfigurieren.
Auch wenn es nur selten vorkommen sollte, kann es notwendig sein, diese Metadaten im IDP neu zu laden, wenn SAML-Zertifikate geändert werden.
In einem solchen Szenario sollten Unternehmen, die den Standard nicht geändert haben und keine Signatur oder Verschlüsselung implementieren, die Daten aktualisieren, auch wenn dies mit Verzögerung geschieht und nicht zu einer Unterbrechung der Dienste führt.
Diese Zertifikatsaktualisierung wäre nur für Unternehmen obligatorisch, die die Standardkonfiguration geändert und SAML-Anfragesignaturen und/oder die Verschlüsselung von SAML-Assertions aktiviert haben. Für diese Unternehmen MUSS der IdP-Administrator die Rainbow-Zertifikatsdaten aktualisieren, um eine Unterbrechung des Dienstes zu vermeiden.
Verfahren:
Die SAML-Metadaten stehen im Menü Einstellungen>Sicherheit des Rainbow-Administrators zum Download bereit:
Wir empfehlen, wann immer es möglich ist, eine regelmäßige Umfrage der Rainbow-Metadaten unter Verwendung der im Abschnitt entityID der SAML-Metadaten angegebenen URL zu aktivieren. So vermeiden Sie manuelle Eingriffe im Falle einer Änderung.
https://openrainbow.com/api/rainbow/authentication/v1.0/saml/xxxx/metadata.xml
Bei IDP-Servern, die keine auf einer URL basierende Umfragemethode vorschlagen, müssen die Metadaten manuell hochgeladen werden. ALE würde eine Benachrichtigung veröffentlichen, wenn dies erforderlich ist.
Für Azure AD muss dies manuell erfolgen:
Für ADFS, in Relying Party Trust, Registerkarte "Signatur":
Das alte Zertifikat muss entfernt und durch das neue aus der Metadaten-Datei ersetzt werden.
Hinweis: Für das aktuelle selbstsignierte Zertifikat müssen Sie es zum Trusted Root Authority Trust Store hinzufügen.
Optionaler Schritt:
Die Verschlüsselung der SAML-Assertion ist nicht erforderlich, da der Datenaustausch über HTTPSbereits verschlüsselt ist .
Wenn jedoch die Verschlüsselung auf dem IDP aktiviert wurde, müssen Sie das alte Zertifikat entfernen und das neue auf der Registerkarte "Verschlüsselung" hinzufügen:
Rational über die Verwendung eines selbstsignierten Zertifikats:
Um die Komplexität der Verwaltung der Erneuerung von SAML-Zertifikaten zu verringern und um mit einer Vielzahl von SAML-Servern und dem neuesten Stand der Technik kompatibel zu sein, verwendet Rainbow jetzt ein selbstsigniertes Zertifikat mit langer Laufzeit. Dies ermöglicht eine langfristige Lösung, ohne die Sicherheit zu beeinträchtigen, da ALE die ordnungsgemäße Handhabung dieser Zertifikatsverwaltung garantiert.
Warum verwenden wir selbstsignierte Zertifikate für die SAML-Funktion in Rainbow?
Durch die Verwendung von SAML 2.0 hat Rainbow eine spezielle URL implementiert, über die die Metadaten eines Unternehmens übermittelt werden können. Sie enthält das Zertifikat, das für die Signaturvalidierung und als Verschlüsselungsempfänger verwendet werden soll.
Das Unternehmen, das die Metadaten verwendet, um seine IDP auf seine spezifische Weise zu konfigurieren, kann sie von Rainbow entweder über einen API-Anruf oder mit einem Webclient zurückholen. In beiden Fällen wird ein HTTPS-Kanal mit normaler Zertifikatsvalidierung verwendet. Man nennt dies einen sicheren Kommunikationskanal.
Auf diese Weise können Metadaten, die für ein Unternehmen in Rainbow zurückgeholt werden, als vertrauenswürdige Metadaten betrachtet werden. Da es sich um vertrauenswürdige Metadaten handelt, gilt der darin enthaltene Zertifikatsblob als vertrauenswürdig.
Da dieses Zertifikat (aus den vertrauenswürdigen Metadaten) per Definition vertrauenswürdig ist, bietet die Verwendung eines von einer Zertifizierungsstelle signierten Zertifikats keinen nennenswerten Vorteil gegenüber der Verwendung eines selbst signierten Zertifikats. Es gibt also keinen Grund, ein von einer Zertifizierungsstelle signiertes Zertifikat zu verwenden, und einige Gründe, dies nicht zu tun. So kann es beispielsweise in einigen Fällen empfehlenswert sein, Zertifikate mit einer Gültigkeit von mindestens 10 Jahren zu verwenden, um eine häufige Erneuerung in Ihrer Umgebung zu vermeiden, die zu manuellen oder Sicherheitsfehlern führen könnte.