Java Security Models | Java Security Solutions

The Java platform has two main goals for security: One is to provide a secure platform on which to run Java-enabled applications, and the other is to provide security tools and services to enable secure applications. The Java platform security at first used the sandbox model, a collection of safe resources that unauthorized code could access, and now it has evolved into a policy-based security model.

The sandbox model

The sandbox model refers to the original security model provided by the Java platform. It provided a very restricted environment to run untrusted code. The basic idea was that downloaded code, such as an applet, was not trusted and, therefore, should not access vital resources (such as the file system). Local code, however, was trusted and had full access to system resources. Figure 26-1 shows the original sandbox model.

Figure 26-1: The original sandbox model

This model was very restrictive so the JDK 1.1 introduced the concept of signed applets . Applets are digitally signed to obtain extra permissions outside of the sandbox. Programs that are not digitally signed continue to be restricted by the original sandbox model. Java 1.1, however, gave unrestricted access to system resources to signed applets. It was an all-or-nothing type of access.

Tip	Recall from Chapter 8 that applets can be signed (as well as configured) using the policytool .

The Extended Java Sandbox is the default model for digitally signed applets. Under the Extended Java Sandbox, digitally signed Java code is allowed to read and write to a specified directory. In that directory, no executables can run and other Java programs cannot gain access to other network services.

Next, in JDK 1.2, the Java Protected Domains Security model gives fine-grain control and selectively grants access to network resources. Under this model, administrators can tailor security policies to match security requirements. For instance, the administrator may grant read access to some files in a directory to all users and write access to managers, all based on the resource being accessed and the identity of the user . The concept of domains is important and is a base for system security.

A domain is a group of permissions that are provided to Java code. These permissions are based on the program's origin and its digital signature. The problem with protected domains is that the policy file needs to be modified by the end user, and this requirement is impractical .

Security in J2SDK v 1.4

The J2SDK v 1.4 has enhanced its security; you may want to look at the http://java.sun.com/security/index.html site for more information. That site includes documentation, user guides, and articles specific to Java security.

Now the J2SDK provides a security model that is policy-based, which is easily configurable and provides fine-grained access control. The policy guards a resource and specifies which permissions are available. Unless permission is granted to code to access a protected resource, the code cannot access it. This access control can be specified for all Java code such as applications, beans, and applets. There is no longer a built-in concept that all local code is trusted.

Here is a brief summary of the security changes included in the J2SDK v 1.4:

The following packages are now integrated into the SDK instead of being optional packages:
- The Java Cryptography Extension (JCE). Recall that, for import control restrictions, the jurisdiction policy files allow strong but limited cryptography.
  
  Cross-Reference
  For more information on JCE, refer to Chapter 15.
- The Java Secure Socket Extension (JSSE). Recall that the JSSE implementation, because of import control restrictions, includes strong cipher suites but does not allow the default SSLSocketFactory and SSLServerSocketFactory to be replaced .
  
  Cross-Reference
  Chapter 23 describes JSSE in more detail.
- Java Authentication and Authorization Services (JAAS). The integration of JAAS into the J2SDK makes it possible for the java.security.Policy API to handle principal-based queries and for the default implementation policy to support principal-based grant entries. This makes it possible to allow access control, based not only on the code that is running but also on who is running it.
Cross-Reference
Refer to Chapter 15 and Chapter 19 for more information on JAAS.
The Java Certification Path API includes new classes and methods to allow building and validating certificate chains.
The Java GSS-API can be used for exchanging messages between applications using Kerberos v5.

Cross-Reference
Chapter 17 describes the Java GSS-API in more detail.
The graphical policytool utility now enables you to indicate via the Principal field that a user is granted specified access control permissions.

Cross-Reference
Chapter 8 and Chapter 18 describe the policytool .
In J2SDK v 1.4, the lifetime of class and permission binding is scoped by the lifetime of the security policy. In previous versions of the SDK, while the class was being loaded, the class was bound with its corresponding permissions and this binding was scoped by the lifetime of the class loader.

J2EE security

The J2EE server enforces security at two levels: authentication and authorization. Authentication is the process by which a user proves his or her identity.

Recall that you define roles and permissions to access resources. In addition, the deployer maps the roles to principals. The details of how the EJB server provides authentication is vendor-specific. Some may use the underlying operating system services and others may use some type of Public Key Infrastructure (PKI). Also, the way principal delegation is performed is provider-specific. Recall that the principal of the requestor for a resource is normally propagated. Therefore, the roles and permissions need to be set accordingly . For instance, some beans should be allowed to call other beans that the user may not have access to. This is very similar to the doPrivileged() method in java.security.AccessController .

Note	The doPrivileged() method enables a piece of trusted code to temporarily access more resources than are available directly to the application that called it.

JAAS is Java's default security model to grant permissions based on where the code comes from. Authorization is the process to establish whether the requestor to a resource has the proper rights or permissions to access it. Using JAAS, authorization can be accomplished declaratively and programmatically.

Cross-Reference

J2EE security is discussed in more detail in Chapter 28 in the section "Enterprise Security with EJBs."

Policy file

As mentioned earlier, Java 2 security is policy-based and uses the java.policy file to specify the security policies that control the resources the application (or applet) can access. In the policy reference implementation, the policy can be specified within one or more policy configuration files. Recall that these files contain a list of entries that map the permissions allowed for code from specific sources.

Also, the policy configuration file may contain a keystore entry to look up the public keys of the signers in the grant entries.

Cross-Reference

Chapter 8 talks about the policy file and the keystore entry.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Agile Project Management: Creating Innovative Products (2nd Edition)

OpenSSH: A Survival Guide for Secure Shell Handling (Version 1.0)

Java for RPG Programmers, 2nd Edition

Visual C# 2005 How to Program (2nd Edition)

Introduction to 80x86 Assembly Language and Computer Architecture

PMP Practice Questions Exam Cram 2