This way doesn’t work. Readers more interested in the solution than the process should skip it.

The initial step is to create a keystore if none is already available. There are plenty of online tutorials showing how to do that.

Alternatively, Maven’s encryption capabilities can be used to store passwords in a dedicated settings-security.xml to further improve security.

To create the JAR, invoke the usual command-line and pass both passwords as system properties:

Signing the application JAR must be part of the build process. With Maven, the JAR signer plugin is dedicated to that. Its usage is quite straightforward:

Notice the signedBy keyword followed by the alias name - the same one as in the keystore above.

Once the JAR is signed, the policy file can be updated to make use of it. This requires only the following configuration steps:

Launching the JAR with the policy file

The same launch command can be used without any change:

java -Djava .security.manager -Djava .security.policy = jvm.policy -jar target/spring-petclinic-1.4.2.jar

Unfortunately, it doesn’t work though this particular permission had already been configured!

Caused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128) at org.springframework.util.ReflectionUtils.makeAccessible(ReflectionUtils.java:475) at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:141) at org.springframework.boot.SpringApplication.createSpringFactoriesInstances(SpringApplication.java:420)

The strangest part is that permissions requested before this one work all right. The reason is to be found in the particular structure of the JAR created by the Spring Boot plugin: JAR dependencies are packaged untouched in a BOOT-INF/lib folder in the executable JAR. Then Spring Boot code uses custom class-loading magic to load required classes from there.

JAR signing works by creating a specific hash for each class, and by writing them into the JAR manifest file. During the verification phase, the hash of a class is computed and compared to the hash of the manifest. Hence, permissions related to classes located in the BOOT-INF/classes folder work as expected.

However, the org.springframework.boot.SpringApplication class mentioned in the stack trace above is part of the spring-boot.jar located under BOOT-INF/lib : verification fails as there’s no hash available for the class in the manifest.