"Currently, all JDK system code invokes SecurityManager methods to check the policy currently in effect and perform access control checks. There is typically a security manager (SecurityManager implementation) installed whenever an applet is running; the appletviewer and most browsers, including those from Netscape and Microsoft, install a security manager.
A security manager is not automatically installed when an application is running. To apply the same security policy to an application found on the local file system as to downloaded applets, either the user running the application must invoke the Java virtual machine with the new
command-line argument (which sets the value of the java.security.manager property), as in
java -Djava.security.manager SomeApp
or the application itself must call the setSecurityManager method in the java.lang.System class to install a security manager."
Now If no security manager is specified, the built-in default security manager is utilized (unless the application installs a different security manager)
Upto this point I hope it is clear that always a secutrity manager is in place.
Now the Second part.This one says that we need a policy file to restrict access.
"JDK v. 1.2 security allows one to restrict read and write access to a subset of signers or locations. The runtime system organizes code into individual domains, each of which encloses a set of classes whose instances are granted the same set of permissions. Permissions are granted by an entry in a policy file. " - This policy file can be edited by policytool.
Now the third part.This is regarding digital signatures.
The basic idea in the use of digital signatures is as follows: -
1. You "sign" the document or code using one of your private keys, which you can generate by using keytool or security API methods. That is, you generate a digital signature for the document or code, using the jarsigner tool or API methods.
2. You send to the other person, the "receiver," the document or code and the signature.
3. You also supply the receiver with the public key corresponding to the private key used to generate the signature, if the receiver doesn't already have it.
4. The receiver uses the public key to verify the authenticity of the signature and the integrity of the document/code.
5. A receiver needs to ensure that the public key itself is authentic before reliably using it to check the signature's authenticity. Therefore it is more typical to supply a certificate containing the public key rather than just the public key itself.
Now the Last Part.This part discusses about keystore.
Private keys and their associated public key certificates are stored in password-protected databases called keystores. A keystore can contain two types of entries: 1.the trusted certificate entries 2.key/certificate entries
Each of this contains a private key and the corresponding public key certificate. Each entry in a keystore is identified by an alias.
A keystore owner can have multiple keys in the keystore, accessed via different aliases. An alias is typically named after a particular role in which the keystore owner uses the associated key. An alias may also identify the purpose of the key. For example, the alias signPersonalEmail might be used to identify a keystore entry whose private key is used for signing personal e-mail, and the alias signJarFiles might be used to identify an entry whose private key is used for signing JAR files.
I think Part 1 thru' 4 can be easily related to understand that why Question 2 is true.
There is a very interesting conversation in this link
One might want to go thru' it for more understaning.
Regarding Question 1.- I leave it to you to decide , the rationale..
Joined: Jan 19, 2006
Thank you for detailed reply. Infact even I had thought the response the way U have indicated. But the arc2Patterns where I found the question had suggested the answer the other way. That is when I was surprised.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com