Jconsole: Fernverwaltung, Benachrichtigungen und Logging

Die Vorlage für die Passwortdatei besteht aus Paaren von Rollennamen und den zugehörigen Passwörtern. Hier die Default-Vorlage (wobei die Einträge auskommentiert sind, schließlich möchte man keine Vorlage, die bereits Passwörter enthält).

# monitorRole QED
# controlRole R&D

Man muss also nur die Kommentarzeichen entfernen und die Passwörter ändern. Wie man sieht, stehen sie im Klartext da. Die Namen leiten sich von den Rollen ab, die in der Datei jmxremote.access definiert wurden, die standardmäßig so aussieht:

monitorRole readonly
controlRole readwrite

Dabei wird der Name von einer Zugriffsart für die jeweilige Rolle ergänzt. Davon gibt es nur zwei: reinen Lesezugriff (readonly) für Benutzer, welche die Managementinformationen lesen, aber nicht aktualisieren oder Methoden aufrufen können sollen, und Lese-/Schreibzugriff (readwrite) für den Vollzugriff auf die Management-Beans.

Falls eine Anwendung eine bestimmte Passwortdatei benutzen soll, kann man die Vorlage für die Passwortdatei ins eigene Home-Verzeichnis kopieren und bearbeiten. Um eine Anwendung mit Passwortauthentifizierung auszuführen, muss man zuerst daran denken, dass die entsprechende Eigenschaft standardmäßig auf true steht, weshalb man sie in den obigen Beispielen erst deaktivieren musste. Nun kann man auf das Einstellen dieser Eigenschaft einfach verzichten. Was man allerdings tun muss, ist, der Anwendung den Pfad zur Passwortdatei mitzuteilen. Für dieses Beispiel soll angenommen werden, dass es sich um ein Windowssystem handelt und die Passwortdatei C:passwordsjmxremote.password heißt, mit folgendem Inhalt:

monitorRole watchme
controlRole controlme

Um die Anwendung mit dieser Passwortdatei auszuführen, gibt man folgende Befehle ein …

… und wird sich wundern, dass man sofort die Fehlermeldung erhält, dass die Passwortdatei nicht zugriffsbeschränkt sei. Der Grund hierfür ist einfach: Die Passwörter liegen im Klartext vor, weshalb die JMX-Authentifizierung verlangt, dass die Passwortdatei nur vom Besitzer der Anwendung gelesen und geschrieben werden kann.

Unix-Anwender können gleich zum chmod-Befehl greifen und „chmod 600 Passwortdateiname“ ausführen. Für Windows-Benutzer ist das Ganze allerdings etwas kniffliger. Zuerst muss das Windows-Dateisystem in der Lage sein, diese Art von Zugriffsrechten überhaupt einzustellen. Falls man mit FAT32 arbeitet, hat man Pech gehabt, denn FAT32 bietet diese Funktion nicht.

Wird mit NTFS gearbeitet, kann man die Eigentümerschaft von Dateien einstellen. Hierzu ruft man die „Eigenschaften“ der Passwortdatei auf und wechselt auf die Registerkarte „Sicherheit“. Dort kann man sich als Besitzer Vollzugriff verschaffen und die Option „Berechtigung übergeordneter Objekte… vererben“ deaktivieren. Danach kann man die Anwendung ausführen. Falls die Registerkarte „Sicherheit“ nicht sichtbar ist, muss man für den Ordner die „Einfache Dateifreigabe“ deaktivieren. Auf der Java-Website findet sich hierfür eine Schritt-für-Schritt-Anleitung.

Sobald die Anwendung läuft, kann man die Verbindung zu ihr über die Registerkarte Remote der Jconsole herstellen und den entsprechenden Benutzernahmen samt Passwort eingeben. Damit verfügt man nun über einen einfachen Authentifizierungsmechanismus.

Für Sicherheit auf Produktionsniveau unterstützt JMX auch SSL-Authentifizierung. Dies erfordert einen Austausch von Schlüsseln zwischen Client und Server, damit diese sich gegenseitig authentifizieren können. Dieses Verfahren kann auch in Kombination mit der Passwort-Authentifizierung eingesetzt werden. Die schlechte Nachricht: Die Jconsole selber ermöglicht die Einrichtung eines Schlüsselspeichers nicht, also leider keine SSL-Unterstützung.