Verwaltung vertrauenswürdiger Domänen und Netzwerksicherheit

Anhand dieses Artikels können Sie die von Ihren „custo-manifest“-Erweiterungen verwendeten externen URLs absichern. Sie erfahren, wie Sie vertrauenswürdige Domänen deklarieren, bei Bedarf CORS oder den Zugriff im lokalen Netzwerk konfigurieren und blockierte Anfragen diagnostizieren.

Übersicht

„Custo-Manifest“-Erweiterungen können auf externe URLs zugreifen: REST-API-Aufrufe, in einen Rainbow-Frame eingebettete Webanwendungen oder das Laden dynamischer Inhalte. Um zu steuern, welche Server von Drittanbietern kontaktiert werden dürfen, wendet Rainbow eine in der Rainbow-Verwaltungskonsole konfigurierte Whitelist vertrauenswürdiger Domänen an.

Jede Domäne, die nicht in dieser Liste aufgeführt ist, wird blockiert. Je nach Art der betreffenden Erweiterung äußert sich die Blockierung unterschiedlich – weshalb es Essential ist, diesen Mechanismus zu verstehen, bevor Sie ein Manifest bereitstellen.

Konfiguration vertrauenswürdiger Domänen

Die Liste wird in der Rainbow-Verwaltungskonsole verwaltet:

Unternehmen → Informationen → Anpassung → Domänen für benutzerdefinierte Manifeste

Rainbow-Konsole – Anpassung → Registerkarte „Benutzerdefinierte Manifest-Domänen“

Fügen Sie pro zuzulassender Herkunft einen Eintrag hinzu. Jeder Eintrag muss folgendem Format entsprechen:

<Protokoll>://<Domäne>[:<Port>]

Gültige Beispiele

Ungültige Beispiele

Gültigkeitsbereich der vertrauenswürdigen Domäne

Die Überprüfung der vertrauenswürdigen Domäne gilt einheitlich für URLs, die von Rainbow Extensions im Web und auf dem Desktop verwendet werden.

Auswirkungen auf REST-API-Aufrufe

Erweiterungen, die eine REST-API aufrufen (commandType: „rest“), werden über den Browser abgewickelt. Dabei kommen zwei unabhängige Sicherheitsebenen zum Tragen:

Prüfung der vertrauenswürdigen Domäne (Rainbow-Seite)

Wenn die Herkunft des REST-Servers nicht in der Rainbow-Konsole deklariert ist, zeigt Rainbow beim Laden des Manifests eine Warnung an. Wird die Warnung ignoriert, schlägt der Aufruf zur Laufzeit stillschweigend fehl – es wird keine Fehlermeldung in Rainbow angezeigt.

Behebung: Deklarieren Sie die Herkunft unter „Unternehmen“ → „Anpassung“ → „Benutzerdefinierte Manifest-Domänen“.

CORS (REST-Serverseite)

Selbst wenn die Domäne von Rainbow als vertrauenswürdig eingestuft wird, erzwingt der Browser zusätzlich CORS. Der REST-Server muss in seinen Antworten die folgenden Header zurückgeben:

Access-Control-Allow-Origin: https://web.openrainbow.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

Wenn Sie den Zugriff nicht auf eine bestimmte Herkunftsquelle beschränken müssen, können Sie den Platzhalter verwenden:

Access-Control-Allow-Origin: *

Wenn der Server diese Header nicht zurückgibt, blockiert der Browser den Aufruf, ohne dass in Rainbow eine Meldung angezeigt wird. Wenn Sie den Server verwalten, fügen Sie die CORS-Header hinzu. Andernfalls bitten Sie den Besitzer des Servers, dessen Konfiguration zu aktualisieren.

Zugriff auf das lokale Netzwerk (LNA)

Wenn der REST-Server in einem lokalen oder privaten Netzwerk läuft (z. B. http://192.168.1.100:3300), blockiert der Browser den Aufruf möglicherweise gemäß der Richtlinie zum lokalen Netzwerkzugriff.

Wenn der Browser eine Anfrage an ein privates Netzwerk erkennt, sendet er zunächst eine „Preflight“-OPTIONS-Anfrage mit folgendem Wert:

Access-Control-Request-Private-Network: true

Der Server muss darauf reagieren, indem er „Access-Control-Allow-Private-Network: true“ zu seinen CORS-Headern hinzufügt:

Access-Control-Allow-Origin: https://web.openrainbow.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Private-Network: true

Fehlt dieser Header, blockiert der Browser die Anfrage, selbst wenn die Standard-CORS-Header korrekt sind.

Kontextabhängige Lösungen:

Auswirkungen auf eingebettete Anwendungen

Die Erweiterung „on-main-window-actions“ zeigt eine Webanwendung eines Drittanbieters innerhalb der Rainbow-Oberfläche an. Je nach dem Wert von „Popup“ sind zwei Modi verfügbar.

Ohne „Popup“ – Anwendung innerhalb des Rainbow-Frames

Die Anwendung wird in einem <IFRAME> innerhalb von Rainbow geladen. Es gelten drei Sicherheitsebenen:

Vertrauenswürdige Domänen

Die URL der Anwendung muss in der Rainbow-Konsole deklariert sein. Ist dies nicht der Fall, wird der Frame zwar angezeigt, die Seite bleibt jedoch leer oder es wird ein Sicherheitsfehler des Browsers angezeigt.

CSP / X-Frame-Options der Anwendung

Die Zielanwendung kann die Einbettung in einen iframe selbst verweigern:

So überprüfen Sie dies: Entwicklertools → Registerkarte „Netzwerk“ → Antwort von der Anwendungs-URL → Header überprüfen.

Behebung: Wenn Sie die Kontrolle über die Anwendung haben, lassen Sie die Herkunft „Rainbow“ in „frame-ancestors“ zu. Andernfalls stellen Sie „Popup: true“ ein (siehe §3.2).

SSO-/OAuth-Ablauf über eine Drittanbieter-Domain

Wenn die Anwendung einen Authentifizierungsablauf (SSO, OAuth 2.0, SAML…) verwendet, befindet sich der Identitätsanbieter (IdP) in der Regel auf einer anderen Domäne als die Anwendung. Rainbow lädt diese Weiterleitungen innerhalb desselben Frames – daher müssen alle Domänen im Ablauf deklariert werden:

https://app.example.com ← die Anwendung
https://login.microsoftonline.com ← Microsoft-IdP
https://login.example.com ← Ihr interner IdP

Mit „Popup: true“ – Anwendung in einem eigenen Fenster

Wenn „Popup: true“ eingestellt ist, wird die URL in einem eigenen Browserfenster außerhalb des Rainbow-Frames geöffnet. In diesem Modus:

• ist die Überprüfung der vertrauenswürdigen Domäne durch Rainbow für diese URL deaktiviert.
• Die „X-Frame-Options“- und CSP-Einschränkungen der Anwendung hinsichtlich „frame-ancestors“ spielen keine Rolle.
• SSO-/OAuth-Abläufe funktionieren in ihrem eigenen Fenster wie gewohnt.

„on-main-window-actions“: [{
„name“: „My App“,
„icon“: „${custo.path}\\app.png“,
"Popup": true,
"command": {
"url": "https://app.example.com/",
"params": "user=${localUser.email}"
}
}]

Sonderfall bei lokaler Ausführung

Die lokale Ausführung von Anwendungen oder Skripten mit `commandType: "file"` auf Rainbow Desktop unterliegt nicht den CORS-Regeln des Browsers, den Sicherheitsbeschränkungen für den lokalen Netzwerkzugriff oder den Sicherheits-Headers für iframes.

Häufige Probleme und Fehlerbehebung

Beim Laden des Manifests wird eine Warnung angezeigt

Das Manifest verweist auf eine oder mehrere URLs, deren Ursprung nicht in der Konsole deklariert ist.

Behebung: Fügen Sie die fehlende Herkunft unter „Unternehmen“ → „Anpassung“ → „Benutzerdefinierte Manifest-Domänen“ hinzu.

Ein REST-Aufruf liefert kein Ergebnis

Der Frame bleibt leer

Diagnose-Checkliste

• Die Herkunft ist unter „Unternehmen“ → „Anpassung“ → „Benutzerdefinierte Manifest-Domänen“ deklariert
• Der REST-Server gibt CORS-Header zurück (Access-Control-Allow-Origin)
• Der Server befindet sich nicht in einem lokalen/privaten Netzwerk (LNA – nur Web)
• Die eingebettete App gibt keine restriktiven X-Frame-Options- oder CSP:frame-ancestors-Einstellungen zurück
• Für SSO/OAuth: IdP-Domänen sind ebenfalls als vertrauenswürdig deklariert
• Falls nichts anderes funktioniert: „Popup: true“ wurde für Frames getestet, „Desktop“ wurde für lokale REST-Aufrufe getestet