Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java security evolution and concepts, Part 2

Discover the ins and outs of Java security

By Raghavan N. Srinivas, JavaWorld.com, 07/28/00

Page 5 of 6

The keystore

The keystore is a password-protected database that holds private keys and certificates. The password is selected at the time of creation. Each database entry can be guarded by its own password for extra security. Certificates accepted into the keystore are considered to be trusted. Keystore information can be used and updated by the security tools provided with the SDK.

Aspects of Java 2 Security

Aspects of Java 2 Security can be broadly classified as:

• Core security: the core classes that deal with security
• Security extensions: the optional packages that supplement the platform security
• Security tools: the Java 2 Software Development Kit (SDK) tools pertaining to security
• Application, applet, and plugin security: security deployment

In this article, I have focused on core security. I'll discuss the other aspects in subsequent articles.

Core security

Java 2's security pieces reside primarily in:

• java.lang
• java.security
• java.security.cert
• java.security.interfaces
• java.security.spec

Another Java 2 package, java.security.acl, which exists for historical reasons, has been superseded by classes in the java.security package.

Let's examine each major security-related class in more detail.

java.lang

The java.lang package contains the SecurityManager class discussed above, which allows applications to implement a security policy. Before performing a sensitive operation, the SecurityManager determines the operation's identity and whether it can be performed in its security context. The manager contains many methods that begin with the word check. The invocation of such a check method typically looks like this:

    SecurityManager security = System.getSecurityManager();
    if (security != null) {
        security.checkXXX(argument,  . . . );
    }

The special method checkPermission(java.security.Permission) determines whether an access request indicated by a specified permission should be granted or denied. The default implementation calls:

   AccessController.checkPermission(perm);

If a request is allowed, checkPermission returns quietly. If denied, a SecurityException is thrown. Refer to the "Sidebar 2: Security Exceptions" for an overview of security exceptions.

java.security

java.security contains most security classes and interfaces. It contains classes for access control, parameters for the various cryptographic algorithms, code source, guarded objects, key management, message digests, permission, policy, protection domains, providers, secure class loaders, random number generators, and digital signatures.

The following Java code can be used to produce a permission to read files in the /tmp directory.

FilePermission p = new FilePermission("/tmp/*", "read");

Entries in the policy file can also be used to achieve similar results. The following is a sample entry in the policy file that indicates the granularity of providing access.

// Sample policy file
grant signedBy "signer_names", codeBase "URL" {
    permission permission_class_name "target_name", "action", 
    signedBy "signer_names";
    };

Both the signedBy and codeBase name and value pairs are optional. The signedBy entry is an alias corresponding to the public key certificate of the private key used to sign the code. The alias name is mapped to the certificate in the keystore. The entry below would grant read/write access to all /tmp files if the code were signed by "Duke". The URL where the code originated is irrelevant.