The code signing mechanism and trust policies were modified for the Java 2 platform.
In the MLet class for the Java 2 platform, security is no longer determined when you instantiate the m-let service. Rather, security is enabled or disabled for your entire agent application, including any class loaders used by the m-let service. Class loaders on the Java 2 platform also rely on code signing, but the mechanism is different.
To enable security on the Java 2 platform, launch your agent applications with the java.lang.SecurityManager property on the command line. Then, when the m-let service loads a class through one of its class loaders, the class loader will check the origin and signature of the class against the list of trusted origins and signatures.
The tools involved in signing a class file are the jar, keytool, and jarsigner utilities. On the host where the agent application would like to download a class, you define a set of permissions for signatures and URL origins. Then, you need to use the policytool utility to generate a java.policy file containing the trusted signatures. Please refer to the JDK documentation for the description of these utilities.
When the agent application is launched with a security manager, it will check this policy file to insure that the origin and signature of a downloaded class match a trusted origin and a trusted signature. If they do not match, the code is not trusted and cannot be loaded.
When the agent application is launched without the security manager, all classes and native libraries may be downloaded and instantiated, regardless of their origin and signature, or lack thereof.