Getting to grips with the Java security model
Peter V. Mikhalenko
Published: 24 Apr 2007 16:35 BST
The Java security model, introduced in Java 2, is the basis of highly secured and distributed enterprise Java applications. The model is based on a customisable "sandbox" in which Java software programs can run safely, without potential risk to systems or users. Java security technology includes a large set of APIs, tools and implementations of commonly used security algorithms, mechanisms and protocols.
The architecture of the Java security model
The Java 2 security platform is formed by two parts: Core Java 2 Security Architecture and Java Cryptography Architecture. These two parts are presented in Figure A. The bottom layer components are the two main parts of the Java 2 security platform, and the top layer consists of the security extensions. Three security extensions were separately available until Java 1.3.1 but, starting with Java 1.4, they were integrated into J2SE.
Core Java 2 Security Architecture
This is a part of the Java platform, and it includes the byte code verifier, class loader, security manager, access controller, access rights facilities, policy description tools and so on. Here's a look at the process of Java code execution in Core Java 2 Security Architecture components.
The byte code verifier checks to see if the Java code conforms to the Java Language Specification. There are two steps to this task: (1) the byte code verifier analyses the byte code sequence; (2) the byte code verifier checks references to other classes. For example, if a class accesses another class' method, the byte code verifier checks if it declared as public. Typical operations of byte code verifier check to see: if the byte code begins with the 0xCAFEBABE sequence; if there are lost bytes; if final classes have subclasses (they should not); what types of method arguments there are; and so on.
If everything is okay, class loader translates byte code into Java classes, which are then operated by JVM. Class loaders also ensure that untrusted code cannot interfere with the running of other Java programs. There can be defined different policies to hint if a particular class needs to be loaded. Class loader and Java standard classes can also define if access to particular system resources is allowable for a class by delegating to Security Manager decision rights.
Security Manager is a special class that can be implemented by developer; it points out if a class can access a given resource (for example, file access or network connection). To make such a decision, the Security Manager analyses the source of the request. If access is denied, a java.lang.SecurityException is generated; otherwise, a call is handled in the usual way.
In order to increase flexibility, an application can use another special mechanism called Access Controller. The Java platform provides additional low-level security features, like automatic memory management and strong data typing. This leads to a more robust code and reduces memory corruption and the possibility of vulnerabilities. Access rights control is the most important enhancement in the Java 2 security system. The Java.security package contains classes and interfaces that form the Core Java 2 Security Architecture.
Java Cryptography Architecture (JCA)
This provides the infrastructure for executing the main cryptographic services in the Java platform, including digital signatures, message digests, ciphers, message authentication codes key generators and key factories. JCA also ensures data integrity and provides APIs for all listed features.
JCA is a part of built-in Java packages related to the Java security platform, but it is separate because of its service-oriented nature. Generally speaking, JCA is just an interface, and there can be many implementations for this interface. Sun provides its own implementation of JCA, starting with Java 1.4, and it is fully integrated into the standard Java package. It supports a wide range of standard algorithms, including RSA, DSA, AES, Triple DES, SHA, PKCS#5, RC2 and RC4. JCA is an extensible, full-featured API for building secure applications. It is also algorithm and implementation independent and uses provider-based (pluggable) architecture.
Extensions
The Java platform includes a number of built-in providers that implement a basic set of security services that are widely used today. However, some applications may rely on emerging standards not yet implemented, or on proprietary services. The Java platform supports the installation of custom providers that implement such services. Java Cryptographic Extension, Java Secure Socket Extension and Java Authentication and Authorization Service are the main components of such pluggable interoperability.
Java Cryptographic Extension (JCE)
This is a Sun extension for ciphering and deciphering data blocks and is a part of JCA implementation. JCE was made a Java extension as a conditional of US encryption technologies' export conditions to third-party countries.
Java Secure Socket Extension (JSSE)
The Secure Sockets Layer (SSL) has become the most widely used data protocol with supported data integrity through encryption. JSSE is a standard interface and reference implementation of the SSL protocol. A developer can use another commercial SSL implementation, but common JSSE interfaces can still be used. The modern Java platform contains other secure socket protocols, including Transport Layer Security (TLS), Kerberos, and the Simple Authentication and Security Layer (SASL). JSSE also includes full support of HTTPS over SSL/TLS.
Java Authentication and Authorization Service (JAAS)
This implements access limiting based on user authentication. Together with Access Control, it provides abstract authentication APIs that incorporate a wide range of log-in mechanisms through a pluggable architecture. It also provides a comprehensive policy and permissions API that allows a developer to create and administer applications requiring fine-grained access to security-sensitive resources. A main feature is that it enables single sign-on of multiple authentication mechanisms and fine-grained access to resources based on the identity of the user or code signer. Recent support for time-stamped signatures (starting with Java 5) makes it easier to deploy signed code by avoiding the need to re-sign code when the signer's certificate expires.
Peter V Mikhalenko is a Sun-certified professional who works for Deutsche Bank as a business consultant.
Did you find this article useful?
10 out of 10 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
