Hi,
Last week Oracle released an important Java security update (1.7.0_21) which has some implications on the JIS product and specifically on users running the Java client as an Applet. See release notes [url]http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html[/url]
In case you are using the Java client and you are not sure if you are running as an Applet - most chances that you are running as an Applet so read on. XHTML client is not affected by this update.
In Java 1.7.0_21 Oracle introduced more strict security levels for Applets. The default level “High” which we assume most users will use, will now present a warning dialog with Red marking and opt-out checkbox both when running the signed and unsigned versions of the client. i.e. both -signed.html and .html
Assuming that reducing the security level on the client side per client workstation is unacceptable. The only other way to eliminate this security warning is to make sure every class file and resource in your application is packaged in a Jar file and signed using a CA approved code signing certificate.
Q: Do you support Java 1.7.0_21 ?
A: Obviously we did not have time to perform extensive QA cycle on this release but we will do our best to help customers migrate to it due to the severe security risk of staying on older version of Java.
Q: Software AG already provides signed Jar files so why do I need to sign my application classes ?
A: By default, the JIS signed product code (clfull-signed.jar) is loaded by the unsigned application specific classes generated by designer. This method of work has been identified as a security risk by Oracle and is now discouraged.
Q: So why can’t Software AG sign the whole application for me ?
A: Because your application is, well, your application, it contains your application auto generated code and code extensions.
Q: What do I need to do in order to sign my code ?
A: You need to package all your application specific code into Jar files, then obtain a code signing certificate which identifies your organization. Most organizations should already have such certificate available but if you don’t, expect to pay around 100$ a year to get such certificate from a certification authority. Now use the Java JDK jarsigner utility to sign your Jar files. The whole process is documented by Java and has nothing to do with the JIS product itself.
Q: Can I package and sign all my application classes, 3rd party classes and the product classes extracted from the official product Jar files into one big Jar file ?
A: Yes you can and this will work, but we do not recommend that since it complicates the process of deploying product hotfix and blurs the distinction between product code and application code. We prefer that you keep the product Jar files alone and only package and sign your application Jar files and any 3rd party Jar files you use and trust. Ideally you should package one Jar file per product library. Once all Jar files are signed, place them on your web server and modify the launcher Html page to list all the Jar files required by your application.
Q: What is the performance impact of packaging all the application class files into Jar files ?
A: The trade-off is that initial, one time per release, Applet download will take longer but once the Applet Jar files are fully downloaded into the workstation cache then performance should be a slightly faster.
Q: Does this problem affect the JISAdminServlet (after all this is also a signed Java Applet)
A: No, since the admin servlet is signed and does not load any unsigned resources.
More questions ? Please post them in the forum.
Best regards,
Lior
