Anhand dieses Beispiels möchten wir Ihnen einen konkreten Einsatz von ScriptRunner in einem Unternehmen zeigen:
Die Herausforderung
In komplexen Applikationsumgebungen gibt es die Herausforderung, dass unterschiedliche Java-Anwendungen parallel laufen sollen und dies jeweils eine bestimmte Java-Version voraussetzt. Deshalb müssen auf allen betroffenen Geräten mehrere Java Runtime Environments (JRE) nebeneinander installiert sein, damit die Applikationskompatibilität sichergestellt werden kann. Außerdem müssen diese JREs auch noch administrativ gesteuert werden, damit sie auch nur für die jeweilige Anwendung verwendet werden können, für welche sie auch berechtigt sind.
Dafür gibt es eine kommerzielle Lösung von Oracle „Oracle WebLogic Server“. Die Logik, welche der WebLogic Server nutzt, ist in jeder JRE-Installation bereits verfügbar, aber ungenutzt. Damit bräuchte man nur noch die steuernde Logik zu konfigurieren und man könnte die Funktion auch ohne zusätzliche Kosten nutzen.
Um dieses Problem zu lösen, wurden vier verschiedene Lösungsvorschläge ausgearbeitet. Es wurde explizit die Verteilung und Wartung von Konfigurationsdateien betrachtet.
Daraufhin wurden die unterschiedlichen Ansätze für die Lösungen bewertet und sich für die Eigenvariante entschieden. Um die Anforderungen zu erfüllen, wurden folgende Problemfelder ermittelt.
- alle JRE-Pakete müssen repaketiert werden
- es soll ein automatisches Erstellen der Richtlinien stattfinden
- es muss eine Richtlinien-Synchronisierungslogik muss entwickelt werden
- es soll ein automatisches Registrieren der JRE-Richtlinie stattfinden
Die Abbildung zeigt die Umgebung:
- Der AppSense Environment Manager ist die Profillösung, die mit dem Active Directory zusammenarbeitet.
- Im AppSense Environment Manager wird eine Konfiguration mit einer logischen Verknüpfung hinterlegt, sodass eine spezielle JRE-Konfiguration nur angewendet wird, wenn zwei JREs bestimmter Versionen zusammen auf einem Client installiert sind.
- Diese Konfiguration wird auf einen Client angewendet.
- Die Konfiguration von AppSense kopiert dann das Zertifikat und das Deployment Rule Set vom APSource-Share. Außerdem wird das Zertifikat in den Globalen Java Zertifikatstore kopiert.
- Mit dem Zertifikat wird das Deployment Rule Set als vertrauenswürdig deklariert und auf die einzelnen Java Applikationen angewendet.
Oracle Java Deployment Rule Sets
Das „Deployment Rule Set“ soll Administratoren in Unternehmen, die zwangsweise ältere Java-Versionen benutzen, ein Werkzeug an die Hand geben, um die Clients anhand von Regeln vor Gefährdungen zu schützen. Allerdings funktioniert das nur in Umgebungen, in denen Clients zentral gesteuert werden. Eine weitere Einschränkung betrifft das Alter der Installation: Alle Client-PCs müssen eine Version des Java-Plugins haben, das zurzeit von Java SE 6, Update 10 oder später aktuell war.
Sind diese Voraussetzungen erfüllt, dann kann der Administrator mit einem Satz von Regeln bestimmen, welche Java-Applets oder Java-Web-Apps, welche Oracle als Rich Internet Applications (RIAs) zusammenfasst, auf Client-PCs laufen dürfen. Beispielsweise kann der Verantwortliche grundsätzlich alle RIAs verbieten und dann spezifische Ausnahmen in einer White List definieren. Regeln können auf Teile der Application-URL heruntergebrochen werden, wie etwa die Portnummer. Sie können ebenso Anweisungen enthalten, die die Regel auf bestimmte Java-Versionen beschränken.
Darüber hinaus bringt ein Update auf Java Development Kit (JDK) Version 7u40 erhöhte Sicherheitswarnungen bei unsignierten oder selbst signierten Applikationen sowie erweiterte Monitoring- und Diagnose-Werkzeuge für Entwickler. Einschränkungen gelten fortan für Zertifikate mit einer Schlüssellänge kürzer als 1.024 Bit. Anwender solcher Schlüssel erhalten eine Warnung mit der Bitte, längere Schlüssel zu wählen. Darüber hinaus kann der Anwender die Prüfung auf Schlüssellänge aber auch deaktivieren.
Zu guter Letzt hat ab JDK Version 7u40 ein Administrator zentral gesteuerter Clients die Möglichkeit, die Warnungen vor einer veralteten Version abzuschalten, damit die Anwender der Clients nicht versuchen, Updates selbst vorzunehmen.
Signieren der Deployment Rule Set-Datei
Um die RuleSet-Datei zu signieren, benötigt man ein gültiges CodeSigning-Zertifikat. Dieses ist zwei Jahre gültig und muss erneuert werden. Es muss in den JVM-Zertifikatsstore geladen werden, damit die JVM das DeploymentRuleSet als vertrauenswürdig einstuft und anwenden kann. Außerdem muss die Webseite aufgrund der erhöhten Sicherheitsregeln der JVM in den Exception-Sites gelistet sein.
Ein CodeSigning Zertifikat kann auf dem üblichen Weg von einer offiziellen Zertifizierungsstelle bezogen werden.
Erstellen einer Deployment RuleSet-Datei
Hier ist der Prozess zum Erstellen und Installieren einer Deployment RuleSet Datei aufgezeigt.
Um diese Schritte abzuarbeiten werden folgende Dateien benötigt. Diese Dateien sind Bestandteil des JDK und können in verschiedenen Versionen verwendet werden.
|- bin
|- msvcr100.dll
|- keytool.exe
|- jli.dll
|- jarsigner.exe
|- jar.exe
|- lib
|- tools.jar
Für diesen Prozess wurden CMD-Skripte entwickelt, um den Prozess zu vereinfachen.
- CreateCertificate.cmd – wird verwendet, um ein SelfSignedCertificate zu erstellen
- CreateDeploymentRuleSetJAR.cmd – wird verwendet, um ein XML-RuleSet in ein signierte JAR-RuleSet zu konvertieren
- DeployRuleSet.cmd – wird verwendet, um ein signiertes JAR-RuleSet in das JRE-Verzeichnis zu kopieren und das erstellte SeldSignedCertificate in den JRE-CertificateStore zu importieren
Der Einsatz von ScriptRunner
Zur Automation von diesem Prozess wurde ScriptRunner verwendet. Die Software hat hier mehrere Funktionen:
- Erstellen einer exception.sites Datei
- Erstellen einer ruleset.xml-Datei
- Konvertieren einer ruleset.xml in eine DeploymentRuleset.jar
Fazit
Mit der Automation in ScriptRunner wurde vor allem der Erstellung dieser Dateien deutlich vereinfacht, da diese oft umständlich oder die Syntax der einzelnen Tools nicht wirklich durchsichtig ist. Außerdem war es das Ziel, diese Lösung in den Betrieb zu überführen und keinen Consultant dort einzusetzen zu müssen, der erweiterte Java Konfiguration Kenntnisse hat. Es wurde dadurch auch eine hohe Reproduzierbarkeit sichergestellt, sodass die DeploymentRuleset.jar immer mit der gleichen Methodik erstellt wird und es keine Fehler in der Konfiguration mehr gibt.
Zusammenhängende Posts
Über den Autor:
Daniel Finkenzeller ist Consultant bei der AppSphere AG und Gastautor auf dem ScriptRunner Blog.