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.
- 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.
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
<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.
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
<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>
- 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.
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
<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.
URL | Transportschutz | Benutzerauthentifizierung | Rollenbasierte Berechtigung |
---|---|---|---|
MyPortlet1/* | HTTPS | Ohne | Ohne |
MyPortlet2/* | Ohne | Ja | Ja (Manager) |
MyPortlet3/* | HTTPS | Ohne | Ohne |
MyPortlet4/* | Ohne | Ja | Ja (Manager) |
<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.
URL | Transportschutz | Benutzerauthentifizierung | Rollenbasierte Berechtigung |
---|---|---|---|
MyPortlet1/* | HTTPS | Ja | Ja (Manager) |
MyPortlet2/* | Ohne | Ja | Ja (Manager) |
MyPortlet3/* | HTTPS | Ohne | Ohne |
MyPortlet4/* | Ohne | Ja | Ja (Manager) |