Introduction:
While researching details for a Java Security Manager article, it became obvious that I didn’t understand the mappings of all the different Java, security-related specifications to the technologies and acronyms I knew. Thus, was the beginning of this article. Below each security-related feature in the Java paradigm is presented and briefly discussed.
Java security features can roughly be split into these categories: Java Standard Edition and Java Enterprise Edition features, and others. The JSE features can be further split into Platform Security, Cryptography, Authentication and Access Control, Secure Communication, and PKI support.The others category covers items such as J2EE Container vendor specific security features and Web Services Security. The documentation uses a different categorization than I have presented here.The first three categories I use are combined into “Platform Security” in the Java documentation.[1]
Java 1.5.0 and J2EE Specification 1.4 will be used as reference.Java Standard Edition (JSE/J2SE) Features
JSE security features are given a high-level overview in [1].
Platform Security
Java Language Security Features
The Java Language provides the following security features: [1]
· Strong data typing
· Automatic memory management
· Bytecode verification
· Secure class loading
These features are enforced by the JVM and Java Compiler[1].
JVM Security Features
The JVM provides automatic memory management (i.e., garbage collection and heap management).It is not possible for a developer to access a pointer to a Java object and directly manipulate the bytes that represent an object; there is only limited access through strongly-typed references.
The JVM, in conjunction with the Java Standard Edition’s libraries, is also required to implement class loadersthat provide for secure class loading.Among other things, this means that only code from trusted locations will be loaded.See [6] for more information.
Once a class is loaded into memory, the JVM is required to inspect Bytecode–Bytecode verification.This basically means the JVM doesn’t trust the compilers.It can run a variety of tests to ensure that Bytecode is in the proper format and plays by the rules it was meant to follow.See [3] for more information.
The JVM is responsible for Run-Time enforcement of strong data typing.Chapter two of JVM specification contains detailed information regarding data types, but this is a summary of information thatis covered in the Java Language specification.
Java Compiler Features
The Java Compiler is responsible for creating correct class files.The Java Language Spec and JVM Spec both provide vital information needed to implement a correct Java Compiler.
By Java Compiler, we are referring to a program that converts correct Java code into Java Virtual Machine instructions (i.e., Java Bytecode).
As well as providing a first-layer of Strong-data typing enforcement.In the presence of Polymorphism, it is not always possible to now all information needed to enforce strong-data typing at compile time.So, the JVM has a role to play in this as well–as described in the last section.
The Java Compiler is responsible for determining the number of local variables that are used by each method.This information is recorded in the class file.During run-time, the JVM must allocate enough space to contain the local variables.Although not dictated by the specification, most JVMs will store this information in the executing thread’s stack frame for the method being called.The JVM will ensure the method’s Bytecode is only allowed to access data in the space allocated for local variables.This feature, in conjunction with strong data-typing,reduces the potential for buffer overflow vulnerabilities that are present in languages such as C/C++.
The Java Compiler is also responsible for deciding how deep each method’s Operand Stack needs to be.This stack is used by the stack-based virtual processor a JVM implements to temporarily store operands and results as Bytecodes are executed.The JVM will enforce this maximum stack size; in this way, the JVM prevents overflows of the Operand Stack.
Cryptography
The Java Cryptography Architecture specificationdefines the cryptographic features of the Java Standard Edition. See [9] for an overview of supported features. JSE provides an algorithm and implementation independent API, which supports many standard cryptographic operations and algorithms.
Authentication And Access Control
The Java Security Architecture specification defines the functionality of the Java Security Manager, which creates a sandbox where Java application can execute safely. The best known use of this sandbox is the JVM running inside of a browser, which executes applets from unknown and potentially-harmful sources. This sandbox provides access control based upon code location and code signers.
Java Authentication and Authorization Service (JAAS) extends the original Java Security Architecture to provide a standard mechanism for authenticating users and giving the Security Manager a concept of an end users identity. Thus,allowing the Security Manager to make access decisions based upon an authenticated user. JAAS can also be used as the framework for implementing custom security models in both JSE and JEE applications. See [11] & [12] for more information.
Although, not formally required by the J2EE Specification, JAAS components are commonly used in the implementation of J2EE Security.
Secure Communication
Java Standard Edition provides secure communication support via JSSE, GSS-API, and SASL.
Full support SSL/TSL is provided through the Java Secure Sockets Extension (JSSE). This is a pure Java implementation of the SSL/TSL protocols. Thinkmiddleware.com has previously written about JSSE in this article. More information about JSSE can be found here.
An alternative secure communication framework called the GSS-API is also available. The GSS-API provides a Java implementation of RFC 2853. GSS-API is a token-based secure communication mechanism. The actual network traffic is not encrypted, as SSL/TSL is, but rather signed, encrypted tokens that cannot be modified without detection are passed over regular TCP sockets.
SASL provides a Java implementation of RFC 2222. Information about SASL can be found here.
Public Key Infrastructure
Provides Java support for X.509 certificates used in SSL/TSL and other security features.The Java Standard Edition provides tools and APIs for working with Public Key Infrastructurekeys and certificates. More information can be found here and here.
Java Enterprise Edition (JEE/J2EE) Features
J2EE Security builds on top of the security features provided by Java Standard Edition. Java 2 Enterprise Edition Security provides a Role-Based Access Control (RBAC) mechanism applications can use, which is enforced by the J2EE Containers. The J2EE Specification lays out the basics of J2EE Security in Chapter three. It provides for authentication and authorization of users interacting with J2EE containers.
Developers can programmatically extend J2EE Security. For example, if you would want to add a maximum, failed login attempts feature, this would require custom coding. But, can be done by extending functionality that J2EE Security already provides.
It is also possible to bypass J2EE Security and implement a custom security implementation for an application running in a J2EE container.
Chapter seven of the J2EE Specification referenced above also requires that EJB Containers implement the CSIv2 protocol. Among other things, this address passing user credentials between EJB clients and servers in different EJB containers.
The specification also requires EJBs, Servlets, and JSPs to be available for SSL/TLS communications.
Vendor Implementations
Every J2EE Container vendor has great latitude in the implementation details of the entire J2EE specificationsecurity is no exception. Websphere, Weblogic, and JBoss (and many others) have their own way of doing things. Each has their own custom security features, above and beyond what the specification calls for, that differentiates the product from its peers.
WS-Security
WS-Security provides for security concerns between Web Services clients and servers. Thinkmiddleware.com briefly reviewed WS-Security features. At some point, we will dig into it further.
Closing Remarks:
Hopefully, this brief summary of the security technologies and specifications available in a Java and J2EE Containers outlines the many options available.
Using these technologies together in a well planned and implemented security model can create robust, secure Java/J2EE applications.
References:
[1] http://java.sun.com/javase/technologies/security/index.jsp
[2] http://java.sun.com/j2se/1.5.0/docs/guide/security/
[3] http://java.sun.com/docs/white/langenv/Security.doc3.html
[4] http://java.sun.com/docs/books/jls/index.html
[5] http://java.sun.com/docs/books/vmspec/
[6] http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc5.html
[7] http://en.wikipedia.org/wiki/Strongly-typed_programming_language
[8] http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html
[9] http://java.sun.com/javase/technologies/security/#overview
[10] http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-specTOC.fm.html
[11] http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASRefGuide.html
[12] http://java.sun.com/developer/technicalArticles/Security/jaasv2/index.html
[13] RFC 2853
[14] RFC 2222
[16] http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
[17] http://java.sun.com/j2se/1.5.0/docs/api/javax/security/sasl/package-summary.html
[18] http://java.sun.com/javase/6/docs/technotes/guides/security/cert3.html
[19] J2EE v1.4 Specification
[20] http://www.javaworld.com/javaworld/jw-07-2004/jw-0726-security.html