Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

Archive for the ‘Java’ Category

Stabiler Betrieb von Oracle Forms-Applikationen mit Deployment Rule Sets (DRS)

with one comment

Oracle Forms-Anwendungen laufen seit vielen Jahren als Java Applet im Browser und benötigen dazu das Java Plug-In im Browser.
Anwender von Oracle Forms stehen vor dem Problem, dass sie nicht in der Lage sind, ihre Anwendungen mit jedem Update des Java Runtime Environments (JRE) zu testen. Zwar gibt es inzwischen die Möglichkeit, neue Java-Versionen als Early Access Releases vorab zu testen (z.B. https://jdk7.java.net/download.html). Dies gilt aber nicht für Security Updates, die ohne Vorankündigung veröffentlicht werden und eventuelle Seiteneffekte in den Forms-Anwendungen verursachen.

Forms-Anwender stecken gewissermaßen in einem Dilemma zwischen Sicherheit (was das Einspielen der aktuellen Security Patches erfordert) und Stabilität (was die Nutzung gründlich getesteter Java-Versionen erfordert). Eine Lösung liegt in der Nutzung der Java  Deployment Rule Sets (DRS), die seit dem JDK 7 Update 40 zur Verfügung stehen. Sie bieten u.a. die Möglichkeit, durch Regeln das Ausführen bestimmter Anwendungen mit bestimmten Java-Versionen festzulegen. Diese Lösung ist insofern auch akzeptabel, da Forms-Applikationen typischerweise im Intranet laufen und hier die Bedrohung durch Sicherheitslücken kaum gegeben ist. Für alle anderen Anwendungen kann die Nutzung der aktuellsten Java-Version oder sogar ein Blockieren der Ausführung festgelegt werden. Deployment Rule Sets können in Verbindung mit Java Applets und WebStart-Anwendungen eingesetzt werden.

Informationen zu den Deployment Rule Sets findet man an folgenden Stellen:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
https://blogs.oracle.com/java-platform-group/entry/deployment_rule_set_by_example

Die Regeln werden in einer XML-Datei (ruleset.xml) festgelegt und zur Ausführungszeit sequentiell abgearbeitet. Neben der Festlegung bestimmter Versionen der JRE können mit Hilfe von Regeln u.a. auch Warnungen unterdrückt sowie die Ausführung von Anwendungen blockiert werden.

Es folgt eine Beschreibung der wesentlichen Schritte zum Einrichten eines Deployment Rule Sets (DRS) zum Ausführen einer Forms-Applikation mit einer bestimmten festgeschriebenen Version der JRE. Da ich nicht auf ein kommerzielles Zertifikat zurückgreifen konnte, entstand der größte Aufwand bei der Erstellung und Einbindung eines eigenen Zertifikats. Auf dem Arbeitsplatz muss eine aktuelle Java-Version (JRE > Java 7 Update 40) installiert sein, die das DRS erkennt und ausführt. Diese startet dann eine zweite Java-Version (dies kann auch eine JRE 6 sein), mit der die Forms-Applikation ausgeführt wird.

  1. URL oder Hash Sign der Anwendung ermitteln, für die eine Regel festgelegt werden soll. Im Falle von Oracle Forms wäre dies z.B. die folgende URL: http://jmenge-de.de.oracle.com:7001/forms/frmservlet.
  2. Anlegen einer Datei ruleset.xml zum Beispiel mit folgendem Inhalt:
    <ruleset version="1.0+">
      <rule>
        <id location="http://jmenge-de.de.oracle.com:7001/forms/frmservlet" />
        <action permission="run" version="1.7.0_25"/>
      </rule>
      <rule>
        <id />
        <action permission="block" />
      </rule>
    </ruleset>
    

    Die Regeln bewirken, dass die Forms-Anwendungen (URL) immer mit der Version 1.7.0_25 ausgeführt werden. An dieser Stelle kann aber auch eine ältere Java-Version (JRE 6) aufgerufen werden.
    Alle anderen Anwendungen (Applets, Java WebStart) werden durch die zweite Regel blockiert.

  3. Die Datei ruleset.xml muss in ein jar-Archiv mit dem Namen DeploymentRuleSet.jar gepackt werden. Dies erfolgt mit dem Befehl:
    jar -cvf DeploymentRuleSet.jar ruleset.xml
    Wichtig ist, dass sich alle Dateien im gleichen Verzeichnis befinden. Die Datei ruleset.xml darf nicht mit einer Pfadangabe im Archiv stehen.
  4. Als nächstes muss das jar-Archiv signiert werden. Das erforderliche Zertifikat kann von einer Certificate Authority (CA) angefordert oder selbst erstellt werden.
    Eine Anleitung zur Signierung mit einem eigenen Zertifikat findet man hier:
    https://blogs.oracle.com/java-platform-group/entry/self_signed_certificates_for_a
    Das signierte jar-Archiv kann anschließend mit dem Befehl
       jarsigner -verify DeploymentRuleSet.jar
    überprüft werden.
  5. Das jar-Archiv muss in ein bestimmtes Verzeichnis auf dem Desktop des Endanwenders kopiert werden. Bei einem MS Windows-System heißt dieses Verzeichnis:
    <Windows Directory>\Sun\Java\Deployment
    und wird in der Regel neu anzulegen sein.
    In der Java Console (Tab Security) kann man jetzt überprüfen, ob das Deployment Rule Set auch tatsähchlich erkannt wurde.
    JavaConsole
  6. Zum Testen muss man jetzt nur noch die Forms-Anwendung übr die festgelegte URL aufrufen.
    Zunächst wird die aktuelle (d.h. sicherste) Version der JRE gestartet. Diese interpretiert das Deployment Rule Set und ruft auf Grund unserer definierten Regel eine ältere (getestete) Version des JRE auf. Dies kann man sehr gut im System Tray von MS Windows erkennen, da nach erfolgreicher Ausführung dort zwei Java-Icons zu sehen sind.
    SystemTray
    Schlägt der Aufruf fehl, geben die Fehlermeldungen einen Hinweis auf die Ursache (z.B. Can not verify self-signed DeploymentRuleSet.jar.).

Wir haben damit erreicht, dass die internen Forms-Anwendungen mit einer stabilen und getesteten Version der JRE ausgeführt werden. Rufen die Anwender eine andere Anwendung (Applet, Java WebStart) im Browser auf, wird die aktuellste Version der JRE verwendet oder wie in unserem Beispiel die Ausführung blockiert.
Die Verwendung der Deployment Rule Sets ist in Verbindung mit Oracle Forms-Anwendungen offiziell supported.

<JM>

 

Written by fmtechteam

07/05/2014 at 11:54

Veröffentlicht in Forms, Java, Jürgen Menge

Derby DB lässt sich nicht starten (Socket Permission on Port 1527)

with 2 comments

In einigen Oracle-Produkten wird die Derby DB intern zur Speicherung von Informationen genutzt. Sie ist zum Beispiel im JDeveloper 12c und in der BI Publisher Trial Edition 11.1.1.x enthalten. Normalerweise wird diese Datenbank auf dem Port 1527 gestartet. Es ist klar, dass zwei gleichzeitig aktive Produkte nicht jeweils eine Derby DB auf demselben Port starten können. Im BI Publisher lässt sich die Port-Nummer ändern, im JDeveloper (noch) nicht. Aber das ist ein anderes Thema.

In diesem Beitrag geht es vor allem darum, dass mit Java7 Update 51 die Sicherheitseinstellungen verschärft wurden und der Zugriff auf Ports zwischen 1025 und 49151 explizit erlaubt werden muss. Ohne diesen expliziten Grant lässt sich die Derby DB nicht mehr starten. Entsprechende Hinweise auf ein Problem findet man in der Datei derby.log bzw. in der Console des JDevelopers, da bestimmte Data Sources (MDS, OWSM, ..) nicht mehr erreicht werden können.

Was ist zu tun?
In der Datei <jdk_location>/jre/lib/security/java.policy muss folgender Eintrag hinzugefügt werden:

grant {
permission java.net.SocketPermission "localhost:1527", "listen";
};

<JM>

Written by fmtechteam

26/02/2014 at 12:56

Veröffentlicht in BI Publisher, Java, Jürgen Menge, JDeveloper

Eine kurze Historie des Java Plug-Ins für Forms

leave a comment »

Wird Oracle Forms als Web-Applikation ausgeführt, wird für die Interaktion mit dem Anwender ein Applet ausgeführt, das ein Java Plug-In im Browser benötigt.
Bis einschließlich Forms 10g wurde als Java Plug-in vor allem der Oracle JInitiator verwendet, der auf dem JDK 1.3 basierte.
Warum Oracle ein eigenes Plug-In bereitstellte, lag vor allem daran, dass es im Java Plug-In von Sun noch einige Bugs gab, die vor allem die Ausführung der Forms-Applikationen stark beeinträchtigte.
Mit der Übernahme des Unternehmens Sun durch Oracle ergaben sich bessere Voraussetzungen, diese Probleme zu beheben. Mit Forms 11g wurde deshalb die Weiterentwicklung des JInitiators eingestellt.

In der Entwicklung des Java Plug-Ins (ehemals Sun, jetzt Oracle)  hat es einige deutliche Zäsuren gegeben.
Ab der Version 1.5.0_06 ist eine dynamische Versionierung möglich. Dies vereinfacht die Administration einer Anwendung, da nicht mehr eine bestimmte Version des Plug-Ins auf dem Client, sondern nur eine Mindestversion gefordert wird. Eine Einschränkung nach oben, d.h. auf ein bestimmtes Release (z.B. JDK 6)  ist über das Family Feature möglich. Siehe dazu folgendes Dokument.
Mit der Version 1.6.0_10 wurde  das Next Generation Plug-In veröffentlicht, dass weitgehende Änderungen mit sich brachte. So laufen die Applets in einer eigenen Java Virtual Machine (JVM) unabhängig vom Prozess des Browsers. Mit Hilfe des Parameters java_version können so innerhalb eines Browsers unterschiedliche Java-Versionen ausgeführt werden. Allerdings muss beachtet werden, dass u.a. dieser Parameter nicht zur Anwendung mit Oracle Forms-Applikationen supportet ist und deshalb auch in der Forms-Dokumentation nicht erwähnt wird. Eine Beschreibung des neuen Verhaltens kann in diesem Dokument nachgelesen werden.
Die letzte größere Veränderung kam mit zunehmenden Sicherheits-Problemen des Java Plug-Ins im Browser. Die Firma Oracle verkündete mit der Version 1.7.0_21 verschärfte Sicherheits-Maßnahmen für künftige Updates, die u.a. die notwendige Signierung aller Applets, ein Tool zum automatischen Entfernen älterer Versionen und erweiterte Warnungen (Alerts) betreffen. Nachzulesen sind diese Erweiterungen in diesem Dokument.
Gerade die zunehmenden Warnungen (Alerts) bei den Anwendern stellen den Administrator von Forms-Anwendungen in Unternehmen vor neue Herausforderungen.

Noch ein wichtiger Hinweis zum Support:
Wird eine bestimmte Version des JDK (und damit auch des Plug-In) in einem Oracle-Produkt verwendet, gelten die Support-Fristen des übergeordneten Produktes (z.B. Oracle Forms), selbst wenn der offizielle Support für die entsprechende Version des JDK ausgelaufen ist (siehe dazu die Note 1557737.1 vom Oracle Support). So ist es auch zu erklären, dass es über den Oracle Support noch Updates für eine bereits abgelaufene Version des JDK geben kann.
So können zum Beispiel nur Kunden mit einem gültigen Wartungsvertrag das JDK 6 Update 51 über MyOracle Support  beziehen (Note 1439822.1).
<JM>

Written by fmtechteam

29/07/2013 at 19:24

Veröffentlicht in Forms, Java, Jürgen Menge