For this there is a commercial solution from Oracle “Oracle WebLogic Server”. The logic used by WebLogic Server is already available in every JRE installation, but unused. With it one would need only to configure the controlling logic and one could use the function also without additional costs.

In order to solve this problem, four different solutions were proposed. The distribution and maintenance of configuration files was explicitly considered.

The different approaches for the solutions were then evaluated and the decision was made in favour of the individual variant. To meet the requirements, the following problem areas were identified.

1. all JRE packages must be repackaged
2. An automatic creation of the guidelines should take place.
3. A policy synchronization logic must be developed.
4. automatic registration of the JRE Directive is to take place

The picture shows the surroundings:

1. AppSense Environment Manager is the profile solution that works with Active Directory.
2. The AppSense Environment Manager stores a configuration with a logical link so that a special JRE configuration is only applied if two JREs of certain versions are installed together on a client.
3. This configuration is applied to a client.
4. The AppSense configuration then copies the certificate and deployment rule set from the APSource share. The certificate is also copied to the Global Java Certificate Store.
5. The certificate declares the deployment rule set to be trustworthy and applies it to the individual Java applications.

Oracle Java Deployment Rule Sets

The “Deployment Rule Set” is intended to provide administrators in companies that are forced to use older Java versions with a tool to protect clients from threats by means of rules. However, this only works in environments where clients are centrally controlled. Another limitation concerns the age of the installation: All client PCs must have a version of the Java plugin that was currently updated from Java SE 6, Update 10 or later.

If these requirements are met, the administrator can use a set of rules to determine which Java applets or Java Web apps, which Oracle summarizes as Rich Internet Applications (RIAs), may run on client PCs. For example, the person in charge can basically prohibit all RIAs and then define specific exceptions in a white list. Rules can be broken down to parts of the application URL, such as the port number. They can also contain instructions that restrict the rule to certain Java versions.

In addition, an update to Java Development Kit (JDK) version 7u40 provides increased security alerts for unsigned or self-signed applications as well as advanced monitoring and diagnostic tools for developers. From now on, restrictions apply to certificates with a key length shorter than 1,024 bits. Users of such keys will receive a warning asking them to select longer keys. In addition, the user can also deactivate the key length check.

Last but not least, JDK Version 7u40 and higher allows an administrator of centrally controlled clients to disable warnings about an outdated version so that the users of the clients do not try to update themselves.

Signing the Deployment Rule Set File

To sign the RuleSet file, a valid CodeSigning certificate is required.

This is valid for two years and must be renewed. It must be loaded into the JVM certificate store for the JVM to classify and apply the DeploymentRuleSet as trustworthy. In addition, the website must be listed in the Exception Sites due to the increased security rules of the JVM.

A CodeSigning certificate can be obtained in the usual way from an official certification body.

Creating a Deployment RuleSet

FileShows the process for creating and installing a Deployment RuleSet file.

The following files are required to complete these steps. These files are part of the JDK and can be used in different versions.

|- bin
|- msvcr100.dll
|- keytool.exe
|- jli.dll
|- jarsigner.exe
|- jar.exe
|- lib
|- tools.jar

CMD scripts were developed for this process to simplify it.

• CreateCertificate.cmd – used to create a SelfSignedCertificate
• CreateDeploymentRuleSetJAR.cmd – is used to convert an XML-RuleSet to a signed JAR-RuleSet.
• DeployRuleSet.cmd – is used to copy a signed JAR-RuleSet into the JRE directory and import the created SeldSignedCertificate into the JRE-CertificateStore.

The use of ScriptRunner

To automate this process, ScriptRunner was used. The software has several functions here:

• Create an exception.sites file
• Creating a ruleset.xml file
• Convert a ruleset.xml to a DeploymentRuleset.jar

Conclusion

With the automation in ScriptRunner, the creation of these files has been greatly simplified, as they are often cumbersome or the syntax of the individual tools is not really transparent. In addition, the goal was to bring this solution into operation without having to employ a consultant with advanced Java configuration knowledge. This also ensures a high reproducibility, so that the DeploymentRuleset.jar is always created with the same methodology and there are no more errors in the configuration.