Sicherheit von Portlet-URLs

WebSphere Application Server ermöglicht den direkten Zugriff auf Portlet-URLs wie auf Servlets. Dieser Abschnitt beschreibt die Sicherheitsaspekte beim Zugriff auf Portlets mit URLs.

Im Bereich der Sicherheit werden Portlets ähnlich wie Servlets behandelt. Die Portlet-Sicherheit verwendet größtenteils die zugrunde liegenden Sicherheitsmechanismen für Servlets. Die Portlet-Sicherheitsinformationen befinden sich jedoch in der Datei portlet.xml, und die Servlet- und JSP-Dateien sind in der Datei web.xml enthalten. Wenn Sie für Portlets Entscheidungen hinsichtlich des Zugriffs treffen, werden außerdem die ggf. in der Datei web.xml enthaltenen Sicherheitsinformationen mit den Sicherheitsinformationen in der Datei portlet.xml kombiniert.

Die Portlet-Sicherheit muss sowohl die programmgesteuerte Sicherheit, d. h. isUserInRole, als auch die deklarative Sicherheit unterstützen. Die programmgesteuerte Sicherheit ist mit der für Servlets identisch. Die Methode isUserInRole für Portlets verwendet jedoch die Informationen aus dem Element "security-role-ref" in der Datei portlet.xml. Die beiden anderen Methoden der programmgesteuerten Sicherheit, getRemoteUser und getUserPrincipal, verhalten sich genauso wie beim Zugriff auf ein Servlet. Beide Methoden geben Informationen zu dem authentifizierten Benutzer zurück, der auf das Portlet zugreift.

Der Aspekt der deklarativen Sicherheit von Portlets wird von den Informationen des Elements security-constraint in der Datei portlet.xml definiert. Diese Bedingungen ähneln den Informationen im Element "security-constraint" von Servlets in der Datei web.xml. Es gibt jedoch folgende Unterschiede:
  • Die Datei portlet.xml enthält kein Element "auth-constraint", das die Namen der Rollen mit Zugriff auf die Ressourcen auflistet. In der Datei portlet.xml ist nur das Element "user-data-constraint" enthalten, das angibt, welcher TLS-Typ (Transport Layer Security) für den Zugriff auf das Portlet erforderlich ist (HTTP oder HTTPS).
  • Zu den Informationen im Element security-constraint der Datei portlet.xml gehört das Element "portlet-collection", die Datei web.xml enthält dagegen das Element "web-resource-collection". Das Element "portlet-collection" enthält nur eine Liste einfacher Portlet-Namen, wohingegen "web-resource-collection" die URL-Muster und die zu schützenden HTTP-Methoden enthält.

Der Portlet-Container ist nicht direkt an der Benutzerauthentifizierung beteiligt. Er fordert Sie beispielsweise nicht auf, die Berechtigungsinformationen zu erfassen. Der Portlet-Container muss vielmehr auf die Benutzerauthentifizierungsverfahren des zugrunde liegenden Servlet-Containers zurückgreifen. Die Informationen im Element "security-constraint" der Datei portlet.xml enthalten demzufolge kein Element "auth-constraint".

Wenn in WebSphere Application Server mit einem URL auf ein Portlet zugegriffen wird, erfolgt die Benutzerauthentifizierung auf der Grundlage der Informationen im Element "security-constraint" für dieses Portlet in der Datei web.xml. Zur Authentifizierung eines Benutzers für ein Portlet muss die Datei "web.xml" demzufolge "security-constraint"-Informationen für dieses Portlet mit relevanten "auth-constraint"-Informationen enthalten. Falls die Datei "web.xml" kein entsprechendes Element "auth-constraint" für das Portlet enthält, ist für das Portlet keine Authentifizierung erforderlich. In diesem Fall ist wie bei einem URL-Muster für ein Servlet ohne "auth-constraints" in der Datei web.xml der Zugriff ohne Authentifizierung erlaubt. Ein "auth-constraint" für ein Portlet kann direkt angegeben werden. Dazu müssen Sie im Element "url-pattern" den Portletnamen angeben. Indirekt können Sie das Element "auth-constraint" mit einem Element "url-pattern" angeben, das das Portlet impliziert.

Achtung: Die Sicherheit von WebSphere Application Server für Portlets funktioniert nur, wenn es kein Servlet und keine JSP mit dem Namen eines Portlets gibt.

Das folgende Beispiel demonstriert, wie anhand der "security-constraint"-Informationen in den Dateien portlet.xml und web.xml in einer Portlet-Anwendung Sicherheitsentscheidungen für Portlets getroffen werden. Das in Aufrufen von "isUserInRole" verwendete Element "security-role-ref" wird hier nicht beschrieben, da es wie bei Servlets verwendet wird.

In den folgenden Beispielen gibt es (sofern nicht anders angegeben) vier Portlets (MyPortlet1, MyPortlet2, MyPortlet3, MyPortlet4), die in portlet.xml definiert sind. Wenn direkt über URLs auf diese Portlets zugegriffen wird, werden sie durch eine Kombination der (ggf. vorhandenen) Informationen in der Datei web.xml geschützt.

Alle Beispiele zeigen den Inhalt der Dateien web.xml und portlet.xml. Verwenden Sie für die Erstellung dieser Implementierungsdeskriptordateien die richtigen Tools, wie Sie es beim Assemblieren einer Portletanwendung tun würden.

Beispiel 1: Die Datei "web.xml" enthält keine "security-constraint"-Daten

Die "security-constraint"-Informationen sind im folgenden Beispiel in der Datei portlet.xml enthalten:
      <security-constraint>
         <display-name>Secure Portlets</display-name>
         <portlet-collection>
         <portlet-name>MyPortlet1</portlet-name>
         <portlet-name>MyPortlet3</portlet-name>
         </portlet-collection>
         <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
         </user-data-constraint>
      </security-constraint>

Wenn Sie in diesem Beispiel mit dem nicht gesicherten Protokoll auf eine Komponente von MyPortlet1 und MyPortlet3 zugreifen, werden Sie über das sichere Protokoll HTTPS umgeleitet. Das Element "transport-guarantee" ist auf die Verwendung sicherer Verbindungen gesetzt. Für MyPortlet2 und MyPortlet4 ist der ungesicherte Zugriff (HTTP) erlaubt, weil das Element "transport-guarantee" nicht gesetzt ist. Die Datei web.xml enthält für keines der vier Portlets entsprechende "security-constraint"-Informationen. Deshalb kann auf alle Portlets ohne Benutzerauthentifizierung und ohne Rollenberechtigung zugegriffen werden. Die einzige Sicherheitskomponente ist in diesem Fall TLS (Transport Layer Security) mit SSL für MyPortlet1 und MyPortlet3.

.
Tabelle 1. Sicherheitsvorgaben für die einzelnen Portlets. In der folgenden Tabelle sind die Sicherheitsvorgaben für die einzelnen Portlets aufgelistet.
URL Transportschutz Benutzerauthentifizierung Rollenbasierte Berechtigung
/MyPortlet1/* HTTPS Ohne Ohne
/MyPortlet2/* Ohne Ohne Ohne
/MyPortlet3/* HTTPS Ohne Ohne
/MyPortlet4/* Ohne Ohne Ohne

Beispiel 2: Die Datei web.xml enthält portletspezifische "security-constraint"-Daten

Die "security-constraint"-Informationen für das Portlet sind im folgenden Beispiel in der Datei web.xml enthalten. Die Datei portlet.xml ist dieselbe wie im vorherigen Beispiel.
<security-constraint id="SecurityConstraint_1">
    <web-resource-collection id="WebResourceCollection_1">
      <web-resource-name>Protected Area</web-resource-name>
      <url-pattern>/MyPortlet1/*</url-pattern>
      <url-pattern>/MyPortlet2/*</url-pattern>
      </web-resource-collection>
    <auth-constraint id="AuthConstraint_1">
      <role-name>Employee</role-name>
    </auth-constraint>
</security-constraint>
Die "security-constraint"-Informationen der Datei web.xml geben in diesem Beispiel an, dass beim Zugriff auf eine der Komponenten von MyPortlet1 und MyPortlet2 eine Benutzerauthentifizierung erforderlich ist. Wenn Sie versuchen, direkt mit URLs auf diese Portlets zuzugreifen und keine Authentifizierungsinformationen verfügbar sind, werden Sie zur Eingabe der entsprechenden Berechtigungsnachweise aufgefordert. Nach der Authentifizierung wird festgestellt, ob Sie zur Rolle "Employee" gehören und zugriffsberechtigt sind. Die Zuordnung von Benutzern/Gruppen zu Rollen erfolgt bei der Implementierung der Portlet-Anwendung. Beachten Sie die folgenden Hinweise zur obigen Datei web.xml:
  • Da die Datei web.xml das Element "url-pattern" verwendet, wurden die Portlet-Namen leicht modifiziert. MyPortlet1 hat jetzt die Bezeichnung /MyPortlet1/*. Der neue Name gibt an, dass alle Komponenten unter dem URL MyPortlet1 geschützt sind. Dies stimmt mit den Informationen in der Datei portlet.xml überein, denn der Sicherheitslaufzeitcode konvertiert das Element "portlet-name" in der Datei portlet.xml in ein Element "url-pattern" (z. B. MyPortlet1 in /MyPortlet1/*), auch für das Element "transport-guarantee".
  • Das Element "http-method" der Datei web.xml wird im Beispiel nicht verwendet, weil alle HTTP-Methoden geschützt werden müssen.
Tabelle 2. Sicherheitsvorgaben für die einzelnen Portlets. In der folgenden Tabelle sind die neuen Integritätsbedingungen für die Sicherheit der einzelnen Portlets aufgelistet.
URL Transportschutz Benutzerauthentifizierung Rollenbasierte Berechtigung
MyPortlet1/* HTTPS Ja Ja (Employee)
MyPortlet2/* Ohne Ja Ja (Employee)
MyPortlet3/* HTTPS Ohne Ohne
MyPortlet4/* Ohne Ohne Ohne

Beispiel 3: Die Datei web.xml enthält generische "security-constraint"-Daten für alle Portlets

Die "security-constraint"-Informationen für das Portlet sind im folgenden Beispiel in der Datei web.xml enthalten. Die Datei portlet.xml ist dieselbe wie im ersten Beispiel.
<security-constraint id="SecurityConstraint_1">
    <web-resource-collection id="WebResourceCollection_1">
      <web-resource-name>Protected Area</web-resource-name>
      <url-pattern>/*</url-pattern>
      </web-resource-collection>
    <auth-constraint id="AuthConstraint_1">
      <role-name>Manager</role-name>
    </auth-constraint>
    </security-constraint>

In diesem Beispiel impliziert /*, dass alle Ressourcen ohne eigene explizite "security-constraints"-Informationen gemäß den Regeln für die URL-Mustererkennung durch die Rolle "Manager" geschützt sein sollen. Da die Datei portlet.xml explizite "security-constraint"-Informationen für MyPortlet1 und MyPortlet3 enthält, sind diese beiden Portlets nicht durch die Rolle "Manager", sondern nur durch den HTTPS-Transport geschützt. Wenn die Datei web.xml jedoch einen implizierenden URL (z. B. /*) enthält, werden aufgrund der URL-Erkennungsregeln alle Portlets mit "security-constraint"-Informationen in der Datei portlet.xml zu ungeschützten Portlets, denn diese Datei kann keine "auth-constraint"-Informationen enthalten.

Im obigen Fall kann ohne Benutzerauthentifizierung auf die Portlets MyPortlet1 und MyPortlet3 zugegriffen werden. Da es für MyPortlet2 und MyPortlet4 jedoch keine "security-constraint"-Angaben in der Datei portlet.xml gibt, wird auf diese Portlets das Muster /* angewendet. Die Portlets sind somit durch die Rolle "Manager", für die eine Benutzerauthentifizierung erforderlich ist, geschützt.

Tabelle 3. Sicherheitsvorgaben für die einzelnen Portlets. In der folgenden Tabelle sind die neuen Integritätsbedingungen für die Sicherheit der einzelnen Portlets in dieser Konfiguration aufgelistet.
URL Transportschutz Benutzerauthentifizierung Rollenbasierte Berechtigung
MyPortlet1/* HTTPS Ohne Ohne
MyPortlet2/* Ohne Ja Ja (Manager)
MyPortlet3/* HTTPS Ohne Ohne
MyPortlet4/* Ohne Ja Ja (Manager)
Falls Sie im obigen Beispiel außerdem ein in der Datei portlet.xml enthaltenes Portlet schützen müssen (z. B. MyPortlet1), sollte die Datei web.xml zusätzlich zu /* einen expliziten "security-constraint"-Eintrag enthalten. Sehen Sie sich dazu das folgende Beispiel an:
<security-constraint id="SecurityConstraint_1">
         <web-resource-collection id="WebResourceCollection_1">
            <web-resource-name>Protected Area</web-resource-name>
            <url-pattern>/*</url-pattern>
            </web-resource-collection>
         <auth-constraint id="AuthConstraint_1">
            <role-name>Manager</role-name>
          </auth-constraint>
      </security-constraint>
      <security-constraint id="SecurityConstraint_2">
         <web-resource-collection id="WebResourceCollection_2">
            <web-resource-name>Protection for MyPortlet1</web-resource-name>
            <url-pattern>/MyPortlet1/*</url-pattern>
            </web-resource-collection>
         <auth-constraint id="AuthConstraint_1">
            <role-name>Manager</role-name>
          </auth-constraint>
      </security-constraint>

In diesem Fall ist MyPortlet1 durch die Rolle "Manager" geschützt und erfordert eine Authentifizierung. Außerdem wird auf das Portlet der "data-constraint"-Wert CONFIDENTIAL angewendet, da die Informationen in den Dateien web.xml und portlet.xml kombiniert werden. MyPortlet3 ist nicht explizit in der Datei web.xml aufgeführt und daher nicht durch die Rolle "Manager" geschützt. Für dieses Portlet ist demzufolge keine Benutzerauthentifizierung erforderlich.

Tabelle 4. Sicherheitsvorgaben für die einzelnen Portlets. Die folgende Tabelle zeigt, wie sich diese Änderung auswirkt.
URL Transportschutz Benutzerauthentifizierung Rollenbasierte Berechtigung
MyPortlet1/* HTTPS Ja Ja (Manager)
MyPortlet2/* Ohne Ja Ja (Manager)
MyPortlet3/* HTTPS Ohne Ohne
MyPortlet4/* Ohne Ja Ja (Manager)

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_portlet_url_sec
Dateiname:csec_portlet_url_sec.html