Beim Festlegen, welche Ressourcen zu schützen sind, sollten Sie alle Komponenten in Betracht ziehen, die eine URL-Zuordnung aufweisen und auf die Ihre Rich UI-Anwendung zugreift:
EGL generiert eine Rich UI-Anwendung in einer HTML-Datei. HTML-Dateien werden in einem Ordner für Webinhalte ('WebContent') Ihres implementierten Projekts generiert (oder in einen Unterordner im Ordner für Webinhalte (WebContent)). Wenn eine HTML-Datei geschützt ist, müssen Sie sich authentifizieren, bevor Sie auf die Rich UI-Anwendung zugreifen, die in der HTML-Datei definiert ist. Zum Schützen der gesamten HTML-Datei können Sie die JEE-Authentifizierung verwenden. Zum Beschränken des Zugriffs auf sensible Bereiche der Rich UI-Anwendung können Sie die angepasste Sicherheit verwenden.
Der EGL Rich UI-Proxy handhabt die Kommunikation zwischen der HTML-Datei, die EGL für eine Rich UI-Anwendung generiert, und Web-Services. Aufgrund der Same Origin-Policy für JavaScript™, kann die HTML-Datei einen Web-Service, der einen anderen Ursprung als die HTML-Datei aufweist (als Protokoll, Domäne und Port definiert), nicht aufrufen. Für den Zugriff auf Web-Services mit anderen Ursprüngen verwendet die HTML-Datei ein Java™-Servlet, das als EGL Rich UI-Proxy bezeichnet wird. Auf alle Web-Services, die in einer Rich UI-Anwendung aufgerufen werden, wird über den Proxy zugegriffen.
Das Servlet für den EGL Rich UI-Proxy hat den Typ 'com.ibm.javart.services.RestServiceServlet' und wird mit der EGL-Laufzeit in der Datei 'fda7.jar' geliefert. Das Servlet wird im selben Projekt implementiert wie die generierte HTML-Datei. Während die HTML-Datei in einem Browser ausgeführt wird, wird der EGL Rich UI-Proxy auf einem Anwendungsserver ausgeführt.
Da die URL des EGL Rich UI-Proxys im JavaScript-Code, der in EGL für Ihre Rich UI-Anwendung generiert wird, sichtbar ist, müssen Sie verhindern, dass außer Ihrem Rich UI-Client noch andere den Proxy zum Aufrufen von Web-Services verwenden. Wenn Sie den Proxy nicht schützen, kann er zum Ausführen von JavaScript-Hijacking-Attacken verwendet werden. Wenn Ihre Rich UI-Anwendung den EGL Rich UI-Proxy nicht verwendet (d. h., die Anwendung ruft keine Web-Services auf), können Sie den Zugriff auf den Proxy in Ihrem implementierten Projekt entfernen. Weitere Informationen finden Sie in Zugriff auf das Servlet des EGL Rich UI-Proxys entfernen. Sie können andernfalls die JEE-Basisauthentifizierung verwenden, um zu verhindern, dass der Proxy von einem nicht authentifizierten Client aufgerufen wird. Zwar kann diese Aktion keinen Schutz gegen Webbedrohungen garantieren; sie verringert jedoch die Möglichkeit, dass eine solche auftritt.
Wenn sowohl die HTML-Datei als auch der EGL Rich UI-Proxy geschützt sind, ist eine Authentifizierung nur erforderlich, bevor Sie auf die HTML-Datei zugreifen können. Wenn der EGL Rich UI-Proxy geschützt ist und die HTML-Datei ist es nicht, ist eine Authentifizierung erforderlich, bevor Sie auf den Proxy zugreifen können (das heißt, bevor die Anwendung einen Web-Service aufruft, der über den Proxy aufgerufen wird).
Sie können zum Schützen von EGL-Web-Services, die in einem Webprojekt generiert werden, die JEE-Sicherheit über die HTTP-Basisauthentifizierung verwenden. Bei der HTTP-Basisauthentifizierung greifen Sie auf sichere Web-Services zu, indem im HTTP-Header eine gültige Benutzer-ID und ein zugehöriges Kennwort übergeben werden. EGL stellt in der Bibliothek 'ServiceLib' die Systemfunktion 'setHTTPBasicAuthentication' bereit, mithilfe der diese Werte in den Header gesetzt werden. Lassen Sie jedem Aufruf eines sicheren Web-Services einen Aufruf von 'setHTTPBasicAuthentication' vorangehen.
Nehmen Sie zum Vermeiden von Sicherheitsrisiken niemals eine feste Codierung der Benutzer-ID und des Kennworts in der Rich UI-Anwendung vor. Die Rich UI-Anwendung sollte stattdessen eine benutzerdefinierte Anmeldeanzeige anzeigen, in der der Benutzer aufgefordert wird, Werte einzugeben, die an 'setHTTPBasicAuthentication' übergeben werden. Sobald Sie über das Kennwort verfügen, können Sie es für weitere Web-Service-Aufrufe in Ihrem Rich-UI-Handler oder einer Bibliothek speichern. Jedes Mal, wenn Sie eine andere Gruppe von Berechtigungsnachweisen an Web-Services übergeben müssen, müssen Sie den Benutzer erneut zur Eingabe auffordern.