Erweiterte Sicherheitsmaßnahmen

In den bisherigen Beispielen wurde der JBoss-Server immer mit der Konfigurationseinstellung »all« gestartet. Hierdurch stehen sämtliche Services und Komponenten des Servers zur Verfügung. Für Test- und Entwicklungssysteme mag das noch in Ordnung sein, bei Produktionssystemen jedoch eher nicht. Hier gilt der Grundsatz: Weniger ist mehr. Nicht gebrauchte Dienste stellen nur ein unnötiges Sicherheitsrisiko dar und sollten somit deaktiviert oder besser noch entfernt werden. Mit der Konfiguration »all« startet JBoss 25 verschiedene Services, mit der Konfiguration »default« sind es nur noch 15. Der Hauptunterschied zwischen den beiden Konfigurationen liegt darin, dass mit »all« sämtliche Cluster-Dienste zur Verfügung stehen, mit »default« jedoch nicht. Wer keinen Cluster benötigt, kommt also mit der Standard-Konfiguration aus. Jedoch bietet es sich an, selbst diese Konfiguration noch etwas abzuspecken, wenn man auf bestimmte Dienste verzichten kann. Hierfür muss der Administrator zuerst ein neues Konfigurationsverzeichnis auf Basis der »default« -Konfiguration erzeugen:

# cp -r /opt/jboss-5.1.0.GA/server/default /opt/jboss-5.1.0.GA/server/custom

In dem Verzeichnis »custom« kann er nun sämtliche Services deaktivieren, die nicht unbedingt notwendig sind. Beispielsweise soll auf einem Produktionssystem sicherlich nicht die JBoss-Startseite sichtbar sein. Der Administrator kann sie entfernen, indem er in »custom/deploy/ROOT.war« löscht oder umbenennt. Wird der Mail-Service nicht gebraucht, kann er die Dateien »custom/deploy/mail-service.xml« und »custom/lib/mail*.jar« löschen. Ein Blick in die »deploy« - und »lib« -Verzeichnisse hilft, weitere unnötige Services zu identifizieren.

JBoss bietet von Haus aus einige Management-Tools, beispielsweise die JMX-Console, die unter der URL »http://localhost:8080/jmx-console/« zu erreichen ist. Mit der Console hat jederman die Möglichkeit, Managed Beans (MBeans) des Servers zu lesen und zu verändern. Die weiter oben angesprochenen Änderungen am Logging-Subsystem hätten so auch mit der JMX-Konsole durchgeführt werden können.

Authentifizierung und Autorisierung

Die JMX-Konsole stellt eine mächtige aber auch gefährliche Möglichkeit dar, den JBoss-Server zu konfigurieren. Auf einem Produktionssystem muss man die Console somit entweder entfernen ( »deploy/jmx-console.war« ) oder aber den Zugang mithilfe einer Benutzerauthentifizierung entsprechend sichern.

Das Sicherheitssystem von JBoss basiert auf dem Java Authentication and Authorization Service (JAAS). Über Sicherheits-Domänen legt der Admin hier fest, welche Art von Login-Modulen für eine bestimmte Anwendung zum Einsatz kommen soll. Es existieren bereits vorgefertige Login-Module für den Zugriff auf Datenbanken, LDAP-Server oder einfache Dateien. Ist eine Webanwendung für eine bestimmte Sicherheits-Domäne konfiguriert, muss sich ein Benutzer beim Zugriff auf diese authentifizieren und bekommt nach erfolgreicher Authentifizierung und Autorisierung eine bestimmte Rolle zugewiesen. Anhand dieser Rolle kann der Admin festlegen, auf welche Teile der Webanwendung der Benutzer zugreifen darf. Eine vordefinierte Sicherheits-Domäne für die JMX-Console ist in Listing 7 dargestellt. Bei diesem Login-Modul handelt es sich um eine einfache Variante, bei der die Authentifizierung und Autorisierung von Benutzern anhand von Dateien stattfindet. Komplexere Beispiele für den Zugriff auf eine Datenbank oder einen LDAP-Server befinden sich jedoch ebenfalls in der Datei »conf/login-config.xml« . Damit eine Anwendung nun weiß, welche Sicherheits-Domäne zum Einsatz kommen soll, ist diese im JBoss-eigenen Deployment-Deskriptor der Anwendung, »jboss-web.xml« zu hinterlegen. Hier ist der Name der Domäne einzutragen, mit der diese sich über das Java Naming and Directory Interface (JNDI) auf dem Server angemeldet hat. Im Falle der JMX-Console muss man also die Datei »deploy/jmx-console.war/WEB-INF/jboss-web.xml« ändern ( Listing 8 ). Hiermit ist nun klar, welche Sicherheits-Domäne und welches Login-Modul für die JMX-Console zum Einsatz kommen.

Es fehlt jedoch noch ein Regelwerk, das bestimmt, wer Zugriff auf welche Ressourcen hat. Diese Information ist der Anwendung nun über den regulären Deployment-Deskriptor »deploy/jmx-console.war/WEB-INF/web.xml« mitzuteilen ( Listing 9 ). Hiermit erhalten nur Benutzer einer bestimmten Rolle Zugriff auf die Console.

Nun fehlen noch die Daten für den Benutzer-Account. Wie im Login-Modul für die Anwendung festgelegt, kommen diese aus den beiden Dateien »props/jmx-console-users.properties« für die Benutzer-Namen und Passwörter, und aus »props/jmx-console-roles.properties« für die Zuordnung einer Rolle zu einem Account. Im Beispiel muss ein Benutzer nun also der Rolle »JBossAdmin« angehören, damit dieser Zugriff auf die Console bekommt. Hat alles funktioniert, sollte sich beim Aufruf von »http://localhost:8080/jmx-console/« ein Fenster öffnen, das den Benutzer zur Authentifizierung auffordert ( Abbildung 5 ).

Abbildung 5: Ein Zugriff auf die Console ist nun erst nach erfolgreicher Benutzeranmeldung möglich.

Andere Webanwendungen lassen sich nun auf ähnliche Art und Weise für eine Benutzer-Authentizierung und Autorisierung konfigurieren. Wichtig ist dabei, dass die verwendete Sicherheits-Domäne sich zuvor beim JNDI registriert hat.