Java-2-Sicherheit

Die Java™-2-Sicherheit-Funktion wird in WebSphere Application Server Liberty unterstützt. Die Java-2-Sicherheit stellt einen auf Richtlinien basierenden differenzierten Zugriffssteuerungsmechanismus bereit, der die Gesamtsystemintegrität verbessert, indem er prüft, ob Berechtigungen vorhanden sind, bevor er den Zugriff auf bestimmte geschützte Systemressourcen erlaubt.

Die Java-2-Sicherheit ist unabhängig von rollenbasierter Java EE-Berechtigung (Java Platform, Enterprise Edition). Die Java-2-Sicherheit überwacht den Zugriff auf Systemressourcen wie die Dateieingabe und -ausgabe, Sockets und Eigenschaften, wohingegen die Sicherheit von Java Platform, Enterprise Edition den Zugriff auf Webressourcen wie Servlets und JSP-Dateien überwacht.

Java-2-Sicherheit für Implementierer und Administratoren

Bevor Sie die Java-2-Sicherheit aktivieren, müssen Sie sicherstellen, dass allen Anwendungen die erforderlichen Berechtigungen erteilt wurden. Andernfalls können die Anwendungen möglicherweise nicht ausgeführt werden. Standardmäßig erhalten die Anwendungen die Berechtigungen über die Spezifikation Java Platform, Enterprise Edition 7.0. Ist eine Anwendung nicht für die Java-2-Sicherheit vorbereitet oder stellt der Anwendungsprovider keine Datei permissions.xml als Teil der Anwendung bereit, können zur Ausführungszeit Zugriffssteuerungsausnahmen der Java-2-Sicherheit ausgelöst werden, wenn die Java-2-Sicherheit aktiviert ist. Auch wenn die Anwendung ausgeführt werden kann, funktioniert sie möglicherweise nicht ordnungsgemäß.

Java-2-Sicherheit für Anwendungsentwickler

Anwendungsentwickler müssen die Berechtigungen kennen, die in der WebSphere-Standardrichtlinie festgelegt sind, und die Berechtigungsvoraussetzungen der Java-SDK-APIs. Sie müssen wissen, ob für die APIs, die ihre Anwendung aufruft, zusätzliche Berechtigungen erforderlich sind. Weitere Informationen zu den erforderlichen Berechtigungen der Java-APIs finden Sie unter Permissions in the Java 2 SDK.
Berechtigungen werden einer Anwendung mit der Datei permissions.xml hinzugefügt und die den aufgelisteten Berechtigungen zugeordnete Codebasis richtet sich nach der Speicherposition der Datei. Die Datei permissions.xml für eine eigenständige .war-Anwendung ist im Verzeichnis META-INF enthalten und alle angegebenen Berechtigungen gelten für alle in der .war-Datei enthaltenen Module. Die Datei permissions.xml für eine .ear-Anwendung befindet sich direkt unter dem Verzeichnis META-INF der .ear-Anwendung selbst und die angegebenen Berechtigungen gelten für alle in der .ear-Datei enthaltenen Module.
Anmerkung: Im Fall der .ear-Anwendung werden permissions.xml-Dateien, die im Verzeichnis META-INF eines anderen Moduls als .ear enthalten sind, ignoriert.

Java-2-Sicherheit aktivieren

Java-2-Sicherheit-Funktionen sind Teil der Kernelerweiterung und werden während des Bootstraps aktiviert, indem die Datei bootstrap.properties mit der Eigenschaft websphere.java.security aktualisiert wird.

Wenn die Eigenschaft websphere.java.security in der Datei bootstrap.properties angegeben ist, wird die Java-2-Sicherheit in Kraft gesetzt. Andernfalls findet keine Berechtigungsprüfung statt.

Eingeschränkte Berechtigungen angeben

Liberty stellt einen Mechanismus bereit, um bei Ausführung einer Web- oder EJB-Anwendungskomponente eingeschränkte Berechtigungen festzulegen. Mit einer eingeschränkten Berechtigung wird sichergestellt, dass keine Instanz dieser Berechtigung einem Bundle oder einer Anwendung erteilt wird. Damit steht ein Mechanismus zur Verfügung, um Anwendungen daran zu hindern, sich selbst mehr Berechtigungen zu erteilen als die notwendigen Berechtigungen, z. B. die Berechtigung, die VM zu verlassen.
Eingeschränkte Berechtigungen werden in den Dateien server.xml und client.xml angegeben. Das folgende Beispiel veranschaulicht, wie die Eigenschaftsberechtigung (PropertyPermission), die zum Schreiben der Systemeigenschaft os.name verwendet wird, eingeschränkt wird. Diese Syntax ist in den Dateien server.xml und client.xml gleich:
<javaPermission className="java.security.PropertyPermission" name="os.name" actions="write" restriction="true" />

Berechtigungen erteilen

OSGi-Bundles können die Berechtigungen, die den Bibliotheken/Klassen innerhalb des Bundles erteilt werden, mit der Datei permissions.perm selbst steuern.

Anwendungen können Berechtigungen ebenfalls selbst steuern, entweder über die Datei permissions.xml oder durch Angabe der erteilten Berechtigungen in den Dateien server.xml und client.xml.

Berechtigungen für das OSGi-Bundle

Die OSGi-Spezifikation stellt einen Mechanismus bereit, um Berechtigungen für ein Bundle mit der Datei permissions.perm im Verzeichnis OSGI INF des Bundles festzulegen. Der Mechanismus ermöglicht eine differenzierte Zugriffssteuerung der Berechtigungen für das Bundle.
Die Datei permissions.perm legt die maximal erforderlichen Berechtigungen für das Bundle fest.
Wichtig: Eine leere Datei permissions.perm ist nicht gleichbedeutend mit einer fehlenden Datei permissions.perm. Wenn Sie Berechtigungen einschränken möchten, vergewissern Sie sich, dass eine permissions.perm-Datei existiert, die nicht leer ist.

Berechtigungen in den Dateien server.xml und client.xml für Anwendungen deklarieren

Berechtigungen ohne angegebene Codebasis, die in den Dateien server.xml und client.xml definiert sind, gelten für alle Anwendungen auf dem betreffenden Liberty-Server.
Sie können die Berechtigungen, die erteilt werden sollen, in den Dateien server.xml und client.xml wie im folgenden Beispiel festlegen. In diesem Beispiel wird die Eigenschaftsberechtigung (PropertyPermission), mit der alle Systemeigenschaften gelesen werden können, erteilt:
<javaPermission className="java.util.PropertyPermission"  name="*" actions="read" />
Sie können die Berechtigungen, die eingeschränkt werden sollen, in den Dateien server.xml und client.xml festlegen. Das folgende Beispiel veranschaulicht, wie die Eigenschaftsberechtigung (PropertyPermission), die zum Schreiben der Systemeigenschaft os.name verwendet wird, eingeschränkt wird. Diese Syntax ist in den Dateien server.xml und client.xml gleich:
<javaPermission className="java.security.PropertyPermission" name="os.name" actions="write" restriction="true" />
Anmerkungen:
  • Für eine eingeschränkte Berechtigung ist restriction auf true gesetzt.
  • Wenn eine Anwendung versucht, sich eine Berechtigung zu erteilen, die als eingeschränkte Berechtigung (restricted) definiert ist, hat die eingeschränkte Berechtigung Vorrang vor der Berechtigungserteilung und die Berechtigung wird nicht erteilt.

Berechtigungen in der Datei permissions.xml für Anwendungen deklarieren

Die Datei permissions.xml ist eine neue Datei, die in der Spezifikation Java EE7 eingeführt wurde. Sie ist unter dem Verzeichnis META-INF einer Anwendung gepackt.

Für Anwendungen, die als eigenständige .war-Datei gepackt sind, gelten die Berechtigungen, die auf der META-INF-WAR-Ebene festgelegt sind, für alle in der .war-Datei gepackten Module und Bibliotheken.

Für Anwendungen, die in einer .ear-Datei gepackt sind, müssen die Berechtigungen auf der Ebene der .ear-Datei deklariert werden. Dieser Berechtigungssatz wird auf alle Module und Bibliotheken angewendet, die in der .ear-Datei oder in einem darin enthaltenen Modul gepackt sind. Eine Datei permissions.xml innerhalb solcher gepackten Module wird ignoriert, unabhängig davon, ob eine Datei permissions.xml für die .ear-Datei selbst bereitgestellt wird.

Für Anwendungen, die in einer .rar-Datei gepackt sind, müssen die Berechtigungen auf der META-INF-RAR-Ebene deklariert werden.

Option "No-rethrow"

Ist die Java-2-Sicherheit aktiviert, löst der JDK-Sicherheitsmanager standardmäßig die Ausnahme java.security.AccessControl aus, wenn ein Berechtigungsverstoß festgestellt wird. Wird die Ausnahme nicht behandelt, kann sie einen Laufzeitfehler zur Folge haben. Zur Unterstützung der Entwickler bei der Vorbereitung ihrer Anwendungen für die Java-2-Sicherheit ist die Option no-rethrow verfügbar. Wenn die Option no-rethrow festgelegt ist, wird die AccessControl-Ausnahme in den Protokollen console.log und messages.log protokolliert, sie bewirkt aber nicht, dass die Anwendung fehlschlägt. Die Option no-rethrow wird aktiviert, indem in der Datei bootstrap.properties die Einstellung websphere.java.security.norethrow=true festgelegt wird. Die Option no-rethrow ist nicht standardmäßig aktiviert. Sie müssen diese Eigenschaft aktivieren, indem Sie sie in der Datei bootstrap.properties angeben.
Anmerkung: Weil diese Eigenschaft verhindert, dass der Sicherheitsmanager eine Ausnahme auslöst, setzt der Sicherheitsmanager die Java-2-Sicherheit streng genommen nicht durch. In einer Produktionsumgebung darf die Eigenschaft no-rethrow nicht verwendet werden.

Dynamische Aktualisierungen

Dynamische Aktualisierungen der Berechtigungsdateien wie permissions.perm, permissions.xml, server.xml und client.xml werden nicht unterstützt. Aktualisierungen von Berechtigungen erfordern einen Neustart des Liberty-Servers.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Nutzungsbedingungen für Information Center | Feedback


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